The bazel -> cmake generator is currently not capable of handling
separate included generated cmake files making use of common C/C++
dependencies.
To work around this limitation, a single generated cmake is now in
place. Long-term, we should either:
* make the cmake generator handle common dependencies gracefully, or
* make the cmake generation aspect travel up `pkg_` rules `srcs`
attributes
so to avoid having to list the targets to be generated in the top-level
`BUILD` file.
Other things fixed:
* removed some warning spam about redefined `BAZEL_CURRENT_REPOSITORY`
* fixed the final link step, that was failing because `libswiftCore.so`
was not being linked.
Our mangler is split in two version:
* `SwiftTrapMangler`, with the same behaviour as the previous
`SwiftMangler`, constructing mangled names with trap label references
* `SwiftRecursiveMangler` that replaces trap label references with
recursive calls to its own `mangle` functions, effectively rolling out
the entire chain of references
The latter is used to create lazy trap file names. Hashing is used to
avoid excessively long filenames.
Specifically, this adds custom formatters using `path::operator string()` and `error_code::message()` and dereferences a (non-empty) optional. `fmtlib` provides formatters for these standard library types in `fmt/std.h`, but that file also requires RTTI (which we disable) for `std::exception` so we can't use it without either patching `fmtlib` (which they're open to: https://github.com/fmtlib/fmt/issues/3170) or enabling RTTI (which will require some consideration).
This reverts commit 0d9dcb161f.
This turns out to introduce a subtle bug related to destruction order
between `Log::instance()` and the `Logger` instances.
New `DIAGNOSE_ERROR` and `DIAGNOSE_CRITICAL` macros are added.
These accept an ID which should indicate a diagnostic source via
a function definition in `codeql::diagnostics`, together with the usual
format + arguments accepted by other `LOG_*` macros.
When the log is flushed, these special logs will result in an error JSON
diagnostic entry in the database.
Finding each extension declaration separately within its parent seemed
to create an `O(n^2)` noticeable performance problem. This is solved
by preloading indexes and storing them in a map, so as to iterate
through the parent of an extension only once per parent instead of once
per extension.
* visiting now happens in a later stage than fetching labels. While
fetching a list of entities to be visited is created, and then acted
upon in actual extraction. This partially flattens the recursive
nature of `fetchLabel` into a loop inside `SwiftVisitor::extract`.
Recursion in `fetchLabel` will only happen on labels fetched while
naming an entity (calling into `SwiftMangler`).
* The choice whether to name a declaration or type has been moved from
the translators to `SwiftMangler`. Acting on this choice is contained
in `SwiftDispatcher::createLabel`.
* The choice whether to emit a body of a declaration has been moved from
`DeclTranslator` to the dispatcher. This choice is also contained in
`SwiftDispatcher::createLabel`.
* The simple functionality of the `LabelStore` has been moved to the
`SwiftDispatcher` as well.
