A cmake generator in bazel is introduced allowing to import the Swift
extractor as a CMake project while keeping Bazel files as the source of
truth for the build.
Using the CMake project:
* requires bazel and clang to be installed and available on the command
line
* does not require a previous bazel build, however
* will require a CMake reconfiguration for changes to generated code
(like changes to the schema)
The information that was contained in `schema.yml` is now in
`swift/schema.py`, which allows a more integrated IDE experience
for writing and navigating it.
Another minor change is that `schema.Class` now has a `str` `group`
field instead of a `pathlib.Path` `dir` one.
This avoids extracting things that are unresolved within an
`IfConfigDecl` instance:
* all conditions
* all inactive code blocks
This is meant to test out the hypothesis that this should solve some
extractor issues. If going through with it we should definitely change
the schema model for this.
Also, tests have not been updated and are expected to fail.
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.
We have found out there can be separate declarations (`VarDecl` or
`AccessorDecl`) which are effectively the same (with equal mangled name)
but come from different clang modules. This is the case for example
for glibc constants like `L_SET` that appear in both `SwiftGlibc` and
`CDispatch`.
In this patch, we simply avoid full deduplication in that case by
appending the module name to the trap key for non-swift modules.
A more solid solution should be found in the future.
This should cover `-merge-modules` mode.
Dumping of the configuration to the target files was moved to a
separate pair of header/source files, as now it is also done in
`SwiftOutputRewrite.cpp`.
Previously we were not extracting any `swiftmodule` file that was not
a system or a built-in one. This was done to avoid re-extracting
`swiftmodule` files that were built previously in the same build, but it
turned out to be too eager, as there are legitimate cases where a
non-system, non-built-in precompiled swift module can be used. An
example of that is the `PackageDescription` module used in Swift
Package Manager manifest files (`Package.swift`).
We now relax the test and trigger module extraction on all loaded
modules that do not have source files (we trigger source file extraction
for those). The catch, is that we also create empty trap files for
current output `swiftmodule` files (including possible alias locations
set up by XCode).
This means that if a following extractor run loads a previously built
`swiftmodule` file, although it will trigger module extraction, this
will however be skipped as it will find its target file already present
(this is done via the `TargetFile` semantics).
