Previously the path to covered files in the __LLVM_COV / __llvm_covmap
section were absolute. This made remote builds with coverage information
difficult because all machines would have to have the same build root.
This change uses the values for `-coverage-prefix-map` to remap files in
the coverage info to relative paths. These paths work correctly with
llvm-cov when it is run from the same source directory as the
compilation, or from a different directory using the `-path-equivalence`
argument.
This is analogous to this change in clang https://reviews.llvm.org/D81122
This commit adds -lto flag for driver to enable LTO at LLVM level.
When -lto=llvm given, compiler emits LLVM bitcode file instead of object
file and perform thin LTO using libLTO.dylib plugin.
When -lto=llvm-full given, perform full LTO instead of thin LTO.
Implement a new "fast" dependency scanning option,
`-scan-dependencies`, in the Swift frontend that determines all
of the source file and module dependencies for a given set of
Swift sources. It covers four forms of modules:
1) Swift (serialized) module files, by reading the module header
2) Swift interface files, by parsing the source code to find imports
3) Swift source modules, by parsing the source code to find imports
4) Clang modules, using Clang's fast dependency scanning tool
A single `-scan-dependencies` operation maps out the full
dependency graph for the given Swift source files, including all
of the Swift and Clang modules that may need to be built, such
that all of the work can be scheduled up front by the Swift
driver or any other build system that understands this
option. The dependency graph is emitted as JSON, which can be
consumed by these other tools.
Some code paths that see target triples go through the frontend
without seeing the driver. Therefore, perform the same "simulator"
inference for x86 iOS/tvOS/watchOS triples also in the frontend,
to ensure that we remain compatible. Also make sure that
-print-target-info performs the appropriate adjustment.
Localize the hack to infer simulator-ness of the target in the driver
itself, when it first processes the target. Emit a warning about the
missing "-simulator" and correct the triple immediately.
This gives a longer grace period for tools that might still not pass
through the simulator environment, while narrowing the hack.
`-no-warnings-as-errors`
This functionality is required for build systems to be able to overload/disable a given Swift project's preference of treating warnings as errors.
Resolves rdar://problem/35699776
This simplifies fixing the master-next build. Upstream LLVM already
has a copy of this function, so on master-next we only need to delete
the Swift copy, reducing the potential for merge conflicts.
Some code paths that see target triples go through the frontend
without seeing the driver. Therefore, perform the same "simulator"
inference for x86 iOS/tvOS/watchOS triples also in the frontend,
to ensure that we remain compatible. Also make sure that
-print-target-info performs the appropriate adjustment.
Localize the hack to infer simulator-ness of the target in the driver
itself, when it first processes the target. Emit a warning about the
missing "-simulator" and correct the triple immediately.
This gives a longer grace period for tools that might still not pass
through the simulator environment, while narrowing the hack.
Recent-ish SDKs for Darwin platforms include an SDKSettings.json
file with version information and Catalyst SDK version mappings. Read
these (when available) and use them to pass the appropriate SDK
version down to the Darwin linker via `-platform_version`.
Finishes rdar://problem/55972144.
Prior to performing linking on ELF platforms (except the PS4) we extract
autolink information from the object files that will be used during linking.
The current implementation passes all the linker inputs that are marked as an
TY_Object to swift-autolink-extract. There are a two cases where this is
not necessary or problematic.
In the first case, we are looking at an ELF shared object. Although
harmless, this is wasted work. Specifically, the `.swift1_autolink_entries`
entry in the object files are marked as `SHF_EXCLUDE`, meaning they will not be
merged into the final product during linking.
In the second case, we are linking against a linker script that looks like an
ELF shared object (ends with `.so`). In the previous case, the autolink-extract
step will succeed even if it does unnecessary work. In this case, the
autolink-extract step will fail because it cannot recognize the linker script as
an object file. You will observe an error something like this:
```
<unknown>:0: error: error opening input file '/path/to/libLinkerScript.so'
(The file was not recognized as a valid object file
```
Although your linker will know what to do with it, autolink-extract will halt
before you get to that point.
This allows the usage of the whole remark infrastructure developed in
LLVM, which includes a new binary format, metadata in object files, etc.
This gets rid of the YAMLTraits-based remark serialization and does the
plumbing for hooking to LLVM's main remark streamer.
For more about the idea behind LLVM's main remark streamer, see the
docs/Remarks.rst changes in https://reviews.llvm.org/D73676.
The flags are now:
* -save-optimization-record: enable remarks, defaults to YAML
* -save-optimization-record=<format>: enable remarks, use <format> for
serialization
* -save-optimization-record-passes <regex>: only serialize passes that
match <regex>.
The YAMLTraits in swift had a different `flow` setting for the debug
location, resulting in some test changes.
When enabled at the driver level, the frontends will inherit the flag. For each frontend that recieves this option, all primaries will have their reference dependencies validated.
Add the platform conditional and set up other basics for the toolchain.
The ConditionalCompilation tests are updated to match, since otherwise
they seem to trip when building on non-OpenBSD platforms. The
Driver/linker test is updated to ensure lld is passed on this platform.
Note that OpenBSD calls "x86_64" as "amd64", so we use that name for the
architecture instead of trying to alias one to the other, as this makes
things simpler.
This reverts commit b1f6a8941c. This
change is causing some instability with incremental builds, so we're
backing it out. Fixes rdar://problem/59016969.
This adds an argument to allow negating `-whole-module-optimization`.
This is useful for cases where it's easier to add an extra flag to your
swiftc invocation rather than removing the original one.
Add support in the driver and frontend for macCatalyst target
targets and library search paths.
The compiler now adds two library search paths for overlays when compiling
for macCatalyst: one for macCatalyst libraries and one for zippered macOS
libraries. The macCatalyst path must take priority over the normal macOS path
so that in the case of 'unzippered twins' the macCatalyst library is
found instead of the macOS library.
To support 'zippered' builds, also add support for a new -target-variant
flag. For zippered libraries, the driver invocation takes both a -target and a
-target-variant flag passes them along to the frontend. We support builds both
when the target is a macOS triple and the target variant is macCatalyst and
also the 'reverse zippered' configuration where the target is macCatalyst and the
target-variant is macOS.
Restructure fine-grained-dependencies to enable unit testing
Get frontend to emit correct swiftdeps file (fine-grained when needed) and only emit dot file for -emit-fine-grained-dependency-sourcefile-dot-files
Use deterministic order for more information outputs.
Set EnableFineGrainedDependencies consistently in frontend.
Tolerate errors that result in null getExtendedNominal()
Fix memory issue by removing node everywhere.
Break up print routine
Be more verbose so it will compile on Linux.
Sort batchable jobs, too.
