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.
Mac Catalyst was introduced with an iOS deployment target of 13.0.
If given a deployment target before that, adjust the deployment target
to 13.0 for the linker.
Standardize the way in which we pass platform version information to
the Darwin linker, using the `-platform_version` option. In the case
of Mac Catalyst, there may be two such platform arguments.
The eventual point of this refactoring is to also pass information
about the SDK version, which `-platform_version` supports but the
mix of `-*_version_min` parameters do not. For now, the SDK
version is stubbed out to 0.0.0, which is this option's "unknown"
value.
Part of rdar://problem/55972144.
When building in batch mode with a precompiled bridging header, tell
the frontends to disable PCH validation. We have always done this for
incremental, non-batch builds, but forgot to update this check when we
added batch mode.
Fixes SR-11986 / rdar://problem/58455465
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.
Handle `-no-toolchain-stdlib-rpath` on Linux/android as well as Darwin. This
enables the flags on other Unix platforms as it can be useful to control the
embedded rpath for the library.
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.
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.
LLVM ships a hardened memory allocator called Scudo:
https://llvm.org/docs/ScudoHardenedAllocator.html. This allocator
provides additional mitigations against heap-based vulnerabilities, but
retains sufficient performance to be safely run in production
applications.
While ideal Swift applications are obviously written in pure Swift, in
practice most applications contain some amount of code written in
less-safe languages. Additionally, plenty of Swift programs themselves
contain unsafe code, particularly when attempting to implement
high-performance data structures. These sources of unsafety introduce
the risk of memory issues, and having the option to use the Scudo
allocator is a useful defense-in-depth tool.
This patch enables `-sanitize=scudo` as an extra `swiftc` flag. This
sanitizer is only supported on Linux, so no further work is required to
enable it on Windows or Apple platforms. As this "sanitizer" is only a
runtime component, we do not require any wider changes to instrument
code. This is similar to clang's `-fsanitize=scudo` flag.
The Swift driver rejects platforms that don't support Scudo using an
existing mechanism in the Driver that is not part of this patch. This
mechanism is in swift::parseSanitizerArgValues(...)
(lib/Option/SanitizerOptions.cpp). The mechanism determines if a
sanitizer is supported by checking for the existence of the
corresponding sanitizer runtime library in the compiler's resource
directory. The Scudo runtime library currently only exists in the
Linux compiler resource directory. This results in the driver only
allowing Scudo when targeting Linux.
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.
The `not env` pattern will result in negating the results of `env`, not
the results of the inferior command. This is dependent on the
implementation of the shell and env. Use the more portable form.
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.
This ensures only one process is generating module cache from an interface
file so that we don't blow up memory usage when multiple processes are
doing the same. The locking mechanism is similar to that of Clang's.
A better approach is that the build system takes care of the module building
step as a formal dependency.
rdar://52839445
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.
* Ignore -wmo when passing -dump-ast
* Cleanup on driver diagnostics
* Remove the FIXME.
* Add support for ignoring `-index-file`
* Revert unrelated formatting changes
* Revert back to only ignoring `-wmo`
Ignoring both `-wmo` and `-index-file` will be harder than just `-wmo`. This is because when calling the compiler and passing `-index-file` after `-dump-ast`, the option gets un-ignored by `Driver::buildOutputInfo`. Therefore, we will just ignore `-wmo` for now.
* Add tests, inspired by `Driver/batch_mode_with_WMO_or_index.swift`
