The `-force-single-frontend-invocation` flag predates WMO and is now an
alias for `-whole-module-optimization`. We should use the latter and let
the former fade into history.
Annotate the covered switches with `llvm_unreachable` to avoid the MSVC
warning which does not recognise the covered switches. This allows us
to avoid a spew of warnings.
Add a mode bit to the dependency collector that respects the frontend flag in the previous commit.
Notably, we now write over the dependency files at the end of the compiler pipeline when this flag is on so that dependency from SILGen and IRGen are properly written to disk.
This moves the standard library response file into the standard library
generation rather than in the driver. Although the driver consumes this
file, it is part of the standard library as it knows its dependencies.
This removes the last of the ICU references in the toolchain.
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.
Teach the driver to pass the SDK version it computes (from the SDK
settings JSON in a Darwin-based platform's SDK) down into the frontend.
The frontend then sets that SDK version in the LLVM module, which
eventually makes its way into the Mach-O file.
Last part of rdar://problem/60332732.
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.
