We do not extract instantiated named types, and instead use the generic
type. But fields of the underlying struct of an instantiated named types
are obtained from the Uses map. We solve this keeping track of which
objects should be overridden by which other objects.
Note that `extractObjectType` calls `extractType` which may add
additional objects to the list that `ForEachObject` loops over, so
we should emit object types as a second pass.
We were trying to convert the object's type to a named type
to iterate through its methods, forgetting that it could also be
a pointer to a named type.
This bug was exposed because we no longer extract an object's
type before extracting it (unless it is a receiver), and when we
extracted a named type we extract its methods and when
extracting a method we extract its receiver and we always give
it the correct label in that situation.
These changes are required to allow a new type-safe approach to TBD
nodes, that will come in a separate commit.
This introduces:
* the possibility to add properties to the root `Element`
* a functor taking tags to the corresponding binding trap entry
* `hasProp()` methods for optional properties in QL
* `getPrimaryQlClass()` method
The main goal here is to get rid of the duplicate definitions of module
`IO`, which currently exist in both `frameworks/core/IO.qll` and
`frameworks/Files.qll`.
We do this by moving the classes inside `Files::IO` to `core/IO.qll`,
but moving most of the actual definitions of those classes to an
internal module `core.internal.FileOrIO`. This means both `Files.qll`
and `IO.qll` can depend on them without leaking them to end users.
Properties marked with `predicate` in the schema are now accepted.
* in the dbscheme, they will translate to a table with a single `id`
column (and the table name will not be pluralized)
* in C++ classes, they will translate to `bool` fields
* in QL classes, they will translate to predicates
Closes https://github.com/github/codeql-c-team/issues/1016
