* 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.
In case the extractor is run in isolation for debugging/testing, this
will avoid littering the current working directory with artifacts, and
instead having a single `extractor-out` directory to inspect or clean
up.
Also extractor logs have been nested into a `swift` directory, as the
log directory provided by the `codeql` cli is actually shared between
languages.
This is done by adding a `isSuccessfullyExtracted` predicate that is
filled for primary files at the very end of the extractor invocation if
the frontend was performed successfully. If for example the extractor
crashes this will therefore not be filled.
The upgrade script is written so that `SuccessfullyExtractedFiles.ql`
on an upgraded script will give exactly the same results as before it.
`weakly_canonical` will resolve as much as possible in the path, and not
return an error if it can't resolve everything (for example due to a
non existant file). In any case in case of problems with the file we
will see an error when actually using the resolved path.
This tunes down some unhelpful log messages.
File hashing is now done internally in `SwiftFileInterception` (and
exported as a `getHashOfRealFile` function for future use in linkage
awareness), and using a per-process in-memory cache. The persistent
caching of paths is removed, so the solution is now robust against input
file changes during the build.
For the same reason, the hash to artifact mapping have the symlinks
reversed now. The artifacts themselves are stored using the hash as
filenames, and the original paths of the artifacts are reacreated in the
scratch dir with symlinks mostly for debugging purposes (to understand
what artifact each hash corresponds to, and to follow what was built by
the extractor).
On macOS `$(CC)` points to a wrapper that requires `DEVELOPER_DIR` to be
set in the environment. Using `clang` is slightly less generic, but
that's our default any way. Even if we do set a different clang version
somewhere, the selected version of GCC would not change, and the test
is targeting that.
Previous to this patch the code contained a workaround for the standard
defect
https://cplusplus.github.io/LWG/issue3657
where `std::filesystem::path` did not have a `std::hash` implementation.
This patch allows compiling against versions of the STL that contain the
fix to the above issue. This is done by running the compiler against
code defining `std::hash<std::filesystem::path>`: if compilation
succeeds, it means the fix is not there and we need to use the
workaround, contained in `PathHash.h.workaround`. Otherwise, the fix is
there and we use `PathHash.h.fixed` instead, which only includes the
standard headers included by `PathHash.h.workaround`, so that one is a
drop-in replacement of the other.
