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
Some Darwin platforms like DriverKit use a system prefix on all of their search paths. Even though DriverKit isn't supported, add support to get the system prefix from SDKSettings when constructing the default search paths.
This requires the DarwinSDKInfo to be gotten earlier in CompilerInvocation, pass that down to ASTContext through CompilerInstance.
-platform-availability-inheritance-map-path is no longer needed to support visionOS in tests, remove that and its supporting code that gets an alternative DarwinSDKInfo.
rdar://166277280
The legacy `module.map` spelling of module map files was deprecated by llvm/llvm-project#75142 and clang expects to remove support for them in the future. Switch all tests to use the supported spelling.
Fixes rdar://128431478.
A header shouldn't contain a function body unless the function is
inline. Following gribozavr's suggestion, I'm using the easier solution
of omitting the semicolon from the function prototype.
(In response to review comments.)
The clang importer has to deal with two virtual file systems, one coming
from clang, and one coming from swift. Currently, if both are set, we
emit a diagnostic that we'll pick the swift one.
This commit changes that, by merging the two virtual file systems. The
motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
(cherry picked from commit 94ef5431ff)
Adds the -vfsoverlay frontend option that enables the user to pass
VFS overlay YAML files to Swift. These files define a (potentially
many-layered) virtual mapping on which we predicate a VFS.
Switch all input-based memory buffer reads in the Frontend to the new
FileSystem-based approach.
This dates back to the early days when the Driver was still being
brought up, but there's no reason to put them together now.
Reorganization and elimination of redundancy only.
Previously we would drop all serialized SIL from partial swiftmodule
files generated while compiling source in non-WMO mode; all that was
missing was linking it in.
This adds a frontend flag, and a test; driver change is coming up
next.
Progress on <rdar://problem/18913977>.
With this, we're out of the business of passing large numbers of input
files on the command line to the frontend, which means we no longer
overflow argv with a mere 1100 input files under whole-module optimization.
In order to make sure this doesn't happen again, I'd like to also get
this working for
- swiftmodule inputs to the merge-module build phase
- /output/ files for multithreading single-frontend builds (WMO)
- object file inputs to the linker on OS X (response files for binutils
ld have different quoting rules)
Part 3 of https://bugs.swift.org/browse/SR-280.
'Ss' appears in manglings tens of thousands of times in the standard library and is also incredibly frequent in other modules. This alone is enough to shrink the standard library by 59KB.
Swift SVN r32409
This performs very conservative dependency generation for each compile task
within a full compilation. Any source file, swiftmodule, or Objective-C
header file that is /touched/ gets added to the dependencies list, which
is written out on a per-input basis at the end of compilation.
This does /not/ handle dependencies for the aggregated swiftmodule, swiftdoc,
generated header, or linked binary. This is just the minimum needed to get
Xcode to recognize what needs to be rebuilt when a header or Swift source
file changes. We can revisit this later.
This finishes <rdar://problem/14899639> for now.
Swift SVN r18045
Ian Anderson
Arnold Schwaighofer
Anthony Latsis
Tony Allevato
Antonio Frighetto
Becca Royal-Gordon
Butta
Ellie Shin
Alex Hoppen
Martin Boehme
David Ungar
Jonas Devlieghere
Erik Eckstein
Robert Widmann
Jordan Rose
Slava Pestov
Joe Groff
Luqman Aden