Previously, const-values output is not supported correctly as it is not
captured correctly as a dependency. The load of the input JSON file is
loaded via file system directly, that can cause issues like:
* False cache hit when the file is changed
* Cannot be prefix mapped to allow distributed caching
Try to support the input file by:
* Correctly capture the input
* Create a new driver flag `-const-gather-protocols-list` that can do
path remapping correctly in swift-driver
rdar://169109358
Every time DarwinSDKInfo reads a new key out of SDKSettings, a boatload of test SDKSettings files need to be updated across several repositories and forks and branches. It’s tedious to be careful to update those with real values so that the tests are properly regression testing older SDKs. It’s important to be careful so that the tests are accurate, e.g. to prevent the scenario where DarwinSDKInfo starts reading a new key out of SDKSettings and assumes that it’s always available everywhere, when in reality it was only added a few releases ago and will break with older SDKs. If the test SDKSettings files continue to be updated ad hoc, it’s going to be really easy to copy/paste a default value everywhere, and then clients will see incorrect behaviors with the real SDKs, or even compiler crashes if the key is unconditionally read. Preemptively add all of the maybe-possibly-compiler relevant keys to the test SDKSettings files from the real SDKs so that the test files are an accurate representation and shouldn't need to be touched in the future. Where the test SDKSettings have intentionally doctored data, add a Comments key explaining what is changed from the real SDK, and alter the SDK name with a tag indicating the change.
rdar://168700857
Fix a corner case when following conditions are met in a single module:
* Module A is imported in the current module
* There exists a versioned `canImport` check for a module A
* All `canImport` check within the module evaluated to false
If all above conditions are met, swift-frontend will not received the
version number from scanner, and it will be confused if version is
either not available (thus a warning, and treat as true), or condition
is not met (eval to false).
Now make sure if when scanner tries to resolve `canImport`, it will
record all instances that a module can be imported, or a version of the
module is found.
rdar://167784812
clang will start looking at CanonicalName and SupportedTargets soon, and error if those aren't as expected in the shipping SDKs. Pre-emptively add those to the test SDKSettings.
rdar://166277280
Fix a programming mistake when chaining bridging header for the main
module. Main module never has the binary module, thus it always need to
chain the bridging header content directly without falling back to
embedded binary module. Previously, the scanner was wrongly error out
because it failed to locate the binary module for main module.
rdar://167707148
When using compilation caching, make sure the debug info emitted in the
swift TU references PCM files via CASID instead of file path. This
allows dsymutil and lldb to load clang modules correctly from CAS,
instead of relying on file system to load the file.
rdar://167054494
This change adds collection of three metrics to the scanner:
- number of Swift module lookups
- number of named Clang module lookups
- recorded number of Clang modules which were imported into a Swift module by name
It introduces '-Rdependency-scan', which acts as a super-set flag to the existing '-Rdependency-scan-cache' and adds emission of the above metrics as remarks when this flag is enabled. Followup changes will add further remarks about dependency scanner progress.
This test is not possible to support on windows as we do not use
`-sysroot` and thus do not have any `-isysroot` flags in the invocation.
As we pick up the "sysroot" through the environment or registry, there
is not much to test here.
Use `FileCheck` for the test validation instead of `diff`. This allows
us to match the different file system arc separator on Windows which is
different across the CAS, where everything is normalised, and the
uncached path where we get mixed paths.
This introduces a new substitution for use in the CAS tests. The plain
variant of the target frontend invokes the tool with the variant target
triple and resource dir only. This allows us to properly invoke the
frontend for the CAS tests.
DLLs on Windows are built/installed into the binary directory while only
import libraries are placed into the library directory to differentitate
between the distributable and developer content. Introduce a helper to
compute the appropriate plugin path.
Add a script to build all dependencies for explicit module build in one
step. This reduces the boiling plate code needed to write a test for
explicit module build and allows the test to be more cross platform and
resilient to module dependencies changes.
These test commands were relying on an arcane Unix specific behaviour
that is non-portable to execute the commands. Python scripts cannot be
run and must be interpreted - they must specify the interpreter.
Explicitly invoke the tools with the configured python interpreter to
allow running the tool on other platforms.
MCCAS wasn't setup correctly when using parallel WMO. Make sure the
CAS ObjectStore and ResultCallbacks are passed to LLVM backend when
using parallel WMO.
rdar://164409895
The search paths for apinotes are leaked when using compilation caching
but they are not needed like other search path because the apinotes are
found and stored inside include-tree.
rdar://164205657
Bring back legacy prefix map option to allow an older swift-driver to
work with newer swift-frontend. For old swift-driver, it will always
send the old style prefix map option, so the new compiler needs to
support that.
rdar://164208526
To support distributed caching for targets that need to use legacy
layout file, the path of legacy layout needs to be remapped.
Current handling of the legacy layout file is to ingest all layout files
to the CAS FileSystem as part of the compiler resource files. But it
cannot convey remapped legacy layout file path to the swift-frontend
when distributed caching is enabled. In order to properly support path
remapping, the legacy layout file is ingested on demand (thus it doesn't
need to be ingested for module compilation), and the remapped path is
communicated to swift-front via frontend flag.
rdar://162793678
Adjust the rule for how bridging header chaining is performed to
increase compatibilities with existing project configuration.
Previously in #84442, bridging header chaining was done via content
concatenation, rather than `#include` via absolute path, to enable prefix
mapping to drop references to absolute path. This triggers an
incompatibility since the directory of the header file is also
considered as part of the search path when resolve the include
directives in the file. Simple concatenation will result in some
`#include` can no longer be resolved.
Now relax the rule to do header content concatenation only when prefix
map is used. This will keep the breakage minimal, and the breakage can
always be fixed by additional include paths when turning on prefix
mapping.
In the future, we should move towards internal bridging header
implementation to avoid the need of chaining completely.
rdar://161854282
To allow prefix mapping of the bridging header to achieve cache hit when
source files are located in different location, the generated chained
bridging header should not include absolute paths of the headers. Fix
the problem by concat the chained bridging header together.
Fixes: https://github.com/swiftlang/swift/issues/84088
Currently, swift-frontend will always try to infer a default CASPath if
no `-cas-path` is passed. The function `getDefaultOnDiskCASPath` called
to infer the default path can fatal error in some environment where no
caching directory and home directory, no matter if caching is used or
not.
Remove the inferred path during parsing since that is not strictly
necessary. If caching is enabled and no CASPath is passed, error can be
issued during CAS construction time.
rdar://158899187
SwiftVerifyEmittedModuleInterface job is configured to be built within
the SubInvocation and it needs to inherit the caching replay prefix map
in order to load macro plugin library correctly.
rdar://158692095
