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.
Also make `visit` in `SwiftDispatcher` work on `const` pointers.
Also, fixed a bug where the guard of a `CaseLabelItem` was not being
extracted, hence the test updates.
With the change to `std::filesystem` some path concatenations were
translated to appending, which is not the same. In case rhs is absolute
`lhs / rhs == rhs`, while concatenating treats `rhs` as if it was
relative. The same behaviour can be obtained in `std::filesystem` by
using `lhs / rhs.relative_path()`.
This replaces usages of `llvm::fs` and string manipulation with
`std::filesystem`, also replacing `std::string` with
`std::filesystem::path` where it made sense.
Moreover MD5 hashing used in macOS file remapping was replaced by
SHA256 hashing using a small header-only SHA256 C++ library with an
MIT license, https://github.com/okdshin/PicoSHA2.
File contents hashing was relocated to the newly created `file` library
for later planned reuse.
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.
Firstly, this change reworks how inter-process races are resolved.
Moreover some responsability reorganization has led to merging
`TrapArena` and `TrapOutput` again into a `TrapDomain` class.
A `TargetFile` class is introduced, that is successfully created
only for the first process that starts processing a given trap output
file. From then on `TargetFile` simply wraps around `<<` stream
operations, dumping them to a temporary file. When `TargetFile::commit`
is called, the temporary file is moved on to the actual target trap
file.
Processes that lose the race can now just ignore the unneeded
extraction and go on, while previously all processes would carry out
all extractions overwriting each other at the end.
Some of the file system logic contained in `SwiftExtractor.cpp` has been
moved to this class, and two TODOs are solved:
* introducing a better inter process file collision avoidance strategy
* better error handling for trap output operations: if unable to write
to the trap file (or carry out other basic file operations), we just
abort.
The changes to `ExprVisitor` and `StmtVisitor` are due to wanting to
hide the raw `TrapDomain::createLabel` from them, and bring more
funcionality under the generic caching/dispatching mechanism.
Now `TypeRepr` is a final class in the AST, which is more or less just
a type with a location in code.
As the frontend does not provide a direct way to get a type from a
type representation, this information must be provided when fetching
the label of a type repr.
This meant:
* removing the type repr field from `EnumIsCaseExpr`: this is a virtual
AST node introduced in place of some kinds of `IsEpxr`. The type
repr is still available from the `ConditionalCheckedCastExpr` wrapped
by this virtual node, and we will rebuild the original `IsExpr` with
the IPA layer.
* some logic to get the type of keypath roots has been added to
`KeyPathExpr`. This was done to keep the `TypeRepr` to `Type` relation
total in the DB, but goes against the design of a dumb extractor. The
logic could be moved to QL in the future
* in the control flow library, `TypeRepr` children are now ignored. As
far as I can tell, there is no runtime evaluation going on in
`TypeRepr`s, so it does not make much sense to have control flow
through them.
