`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.
This is in preparation for the extractor to use shared libraries
packaged alongside it.
We could probably also move the `CODEQL_EXTRACTOR_SWIFT_RUN_UNDER` logic
in it, where it would be simpler and more robust.
The hash map mechanism that was already in use for reading swiftmodule
files on macOS is now in use also on Linux. The output replacing
mechanism has been also reworked so that:
* frontend module emission modes have the remapping done directly in
the internal frontend options instead of painstakingly modifying input
flags (this requires a patch on the swift headers though)
* object emission mode is silenced to be just a type checking pass,
thus producing no output files
* all other passes but some debugging and version related ones become
noops
The open file read redirection uses a global weak pointer instance to
maximize robustness in the face of possibly multi-threaded calls to open
happening while `main` is exiting. Possibly overkill, but better safe
than sorry.
