There were missing extractions from the Builtin (and other) modules.
This was actually caused by two issues:
* we did not visit all required modules, as for example the `Builtin`
module does not appear as being imported by anybody (together with
another mysterious `__Objc` module)
* moreover the `Builtin` module works internally by only creating
declarations on demand, and does not provide a list of its top level
declarations.
The first problem was solved by moving module collection to the actual
visiting. This may mean we extract less modules, as we only extract the
modules we actually use something from (recursively). This change can
be reverted if we feel we need it.
The second one was solved by explicitly listing the builtin symbols
encountered during a normal extraction. This does mean this list needs
to be kept up to date.
Add module context to all declarations. As keeping the `std::variant`s
required slightly more work for this, and we intended to remove them
any way, this is done in this change.
For background, we put those in as we were not extracting all modules at
the time, so we were missing some DB ids that we put back in by adding
the "defining" traps not only in the trap file related to the defining
module but also to the one where the declaration was used. Since then
we fixed module extraction, so this should not be needed any more.
This introduces a `MethodRefExpr` node synthesized out of
`DotSyntaxCallExpr` under the `LookupExpr` hierarchy. This means that
much like
```free_function(1, 2)```
is a `CallExpr` with `getFunction` giving a `DeclRefExpr`,
```foo.method(1, 2)```
is now a `CallExpr` with `getFunction` giving a `MethodRefExpr`.
`ApplyExpr::getStaticTarget` has been made work with it (as well as
`ConstructorRefCallExpr` which for the moment has been left where it
is), a new `MethodApplyExpr` has been introduced deriving from it,
and control and data flow libraries have adapted.
A small but was fixed in `qlgen` where the default constructor for DB
types was not correctly subtracting derived IPA types depending on the
order of definitions in `schema.yml`.
There are still some occurrences of `DotSyntaxCallExpr`, and as already
mentioned the other `SelfApply` class (`ConstructorRefCallExpr`) was
left alone. Their treatment is left for a future PR.
