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.
* [Diagnostics] Turn educational notes on-by-default
* [Diagnostics] Only include educational notes in printed output if -print-educational-notes is passed
* Make -print-educational-notes a driver option
* [Diagnostics] Issue a printed remark if educational notes are available, but disabled
* [docs] Update educational notes documentation and add a contributing guide
* [Diagnostics] Cleanup PrintingDiagnosticConsumer handling of edu notes
* Revert "[Diagnostics] Issue a printed remark if educational notes are available, but disabled"
For now, don't notify users if edu notes are available but disabled. This decision can be reevaluated later.
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
Two more pair of string conversion fixes. With this, I was able to build
swift master-next on Ubuntu 16.04 (didn't try anything downstream of
swift, and not sure if the tests pass).
On the older compiler/stdlib used by our Ubuntu 16.04 bots, the
construction
std::pair<std::string, X>(StringRef, X)
fails unless you call `.str()`. Newer compilers/stdlib treat this as an
explicit construction, which is what is now needed on master-next, so it
only fails on Ubuntu 16.04.
rdar://60514063
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.
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.
Static-linked libraries could add symbols to the final tbd file. We need
this flag to specify additional module names to collect symbols from.
rdar://59399684
This reverts commit b1f6a8941c. This
change is causing some instability with incremental builds, so we're
backing it out. Fixes rdar://problem/59016969.
