WMO stands for whole module optimization. It's a compilation mode where
all sources of a module are compiled together, e.g.
```
swift-frontend -emit-module A.swift B.swift -o Module.swiftmodule
```
This is opposed to incremental mode, where one would do something like
```
swift-frontend -emit-module -primary-file A.swift B.swift -module-name Module -o Module~A.swiftmodule
swift-frontend -emit-module A.swift -primary-file B.swift -module-name Module -o Module~B.swiftmodule
swift-frontend -merge-modules Module~A.swiftmodule Module~B.swiftmodule -o Module.swiftmodule
```
In WMO mode we were skipping extraction of all files after the first
one, because we were filtering in only files with an associated output,
and internally swift only assigns the output to the first input file in
WMO mode (which is just an implementation detail).
This patch refines that filter, by getting all input source files in
case there are no primary inputs.
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.
As discussed [in this accepted proposal][1], parameter labels do not
take part any more in making up a function type, so we need to not
extract them any more to avoid DB inconsistencies.
These were unused in the library, which makes the upgrade and downgrade
scripts have full compatibility.
[1]: 9c53790a13/proposals/0111-remove-arg-label-type-significance.md
`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.
