We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
Add the command line option -require-explicit-availability to detect public
or `@usableFromInline` declarations and warn if they don't declare
an introduction OS version. This option should catch forgotten `@available`
attributes in frameworks where all services are expected to be introduced
by an OS version.
The option -require-explicit-availability-target "macOS 10.14, iOS 12.0"
can be specified for the compiler to suggest fix-its with the missing
attributes `@available(macOS 10.14, iOS 12.0, *)`.
rdar://51001662
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.
rdar://problem/50057445
On Windows, there are multiple variants of the C runtime that must be
explicitly specified and consistently used from the runtime to the
application. The new `-libc` option allows us to control the linking
phase by correctly embedding the requested library to be linked. It is
made into a required parameter on Windows and will add in the
appropriate flags for the imported C headers as well. This ensures that
the C library is not incorrectly linked.
Otherwise the overlays won't be force-loaded when you import them.
(This feature could possibly be scoped back at this point, but it's
not something that should be changed just by using module interfaces!)
This allows us to mark this flag as DoesNotAffectIncrementalBuild, so
that switching between a tty and non-tty doesn't cause full rebuilds
with swiftpm.
https://bugs.swift.org/browse/SR-7982
Leave the old flag in as an alias to the new flag, for transition
purposes. Also go ahead and remove the long-deprecated and unused
`emit-interface-path`.
Part of rdar://49359734
...and remove the option. This is ~technically~ CLI-breaking because
Swift 5 shipped this as a hidden driver option, but it wouldn't have
/done/ anything in Swift 5, so I think it's okay to remove.
Note that if a parseable interface (.swiftinterface) and a binary
interface (.swiftmodule) are both present, the binary one will still
be preferred. This just /allows/ parseable interfaces to be used.
rdar://problem/36885834
By default, we compile the standard library with
`-enforce-exclusivity=unchecked`. If we don't preserve this argument,
then the standard library compiled from an interface includes
exclusivity enforcement, which pessimizes inlining those functions,
which decreases performance for clients.
Part of rdar://46431767
Windows doesn't know what a shebang is, so it's unable to run tests that
use -driver-use-frontend-path with a script. This allows the script
interpreter to be run as the executable with the script as its first
argument. e.g. --driver-use-frontend-path "python;my-script.py"
This patch allows `-serialize-diagnostics-path` for the interpret mode.
There is one file compiled in such mode, so it makes sense to support
this flag to specify an explicit output path for diagnostics emission.
Resolves: SR-9670
<rdar://problem/46548531> Extend @available to support PackageDescription
This introduces a new private availability kind "_PackageDescription" to
allow availability testing by an arbitary version that can be passed
using a new command-line flag "-swiftpm-manifest-version". The semantics
are exactly same as Swift version specific availability. In longer term,
it maybe possible to remove this enhancement once there is
a language-level availability support for 3rd party libraries.
Motivation:
Swift packages are configured using a Package.swift manifest file. The
manifest file uses a library called PackageDescription, which contains
various settings that can be configured for a package. The new additions
in the PackageDescription APIs are gated behind a "tools version" that
every manifest must declare. This means, packages don't automatically
get access to the new APIs. They need to update their declared tools
version in order to use the new API. This is basically similar to the
minimum deployment target version we have for our OSes.
This gating is important for allowing packages to maintain backwards
compatibility. SwiftPM currently checks for API usages at runtime in
order to implement this gating. This works reasonably well but can lead
to a poor experience with features like code-completion and module
interface generation in IDEs and editors (that use sourcekit-lsp) as
SwiftPM has no control over these features.
In the Darwin toolchain the linker is invoked directly, and compiler_rt
is used if it is found, but in Unix platforms, clang++ is invoked
instead, and the clang driver will invoke the linker. Howerver there was
no way of modifying this clang++ invocation, so there's no way of
providing `--rtlib=` and change the platform default (which is normally
libgcc). The only workaround is doing the work that the Swift driver is
doing "manually".
The change adds a new option (with help hidden, but we can change that)
to allow providing extra arguments to the clang++ invocation. The change
is done in the two places in the Unix and Windows toolchains that I
found the clang driver was being used.
Includes some simple tests.
A module compiled with `-enable-private-imports` allows other modules to
import private declarations if the importing source file uses an
``@_private(from: "SourceFile.swift") import statement.
rdar://29318654
Currently, the check for whether to serialize parseable interface
arguments doesn't handle the case where a supplementary output file map
is used, preferring only to check if the frontend is passed
`-emit*interface`. Instead, check if the frontend inputs and outputs
contains a parseable interface, and use that to determine if we need to
save args.
This also puts `-module-link-name` in the parseable interface arg list.
Commit to a command line option spelling so that build systems can
start testing it. I deliberately picked one of the longer names we
were considering because we can always decide to add a shorter alias,
but can't decide a shorter name was too generic.
Like the other supplementary output flags,
-emit-parseable-module-interface-path will emit a .swiftinterface file
to a particular path, while -emit-parseable-module-interface will put
it next to the main output (the one specified with -o).
rdar://problem/43776945
We already have something called "module interfaces" -- it's the
generated interface view that you can see in Xcode, the interface
that's meant for developers using a library. Of course, that's also a
textual format. To reduce confusion, rename the new module stability
feature to "parseable [module] interfaces".
When provided, this flag warns about implicit overrides, where a
declaration overrides another declaration but is not marked with the
‘override’ keyword. The warning can be suppressed by either providing
‘override’ or ‘@_nonoverride’.
At present, this only happens with overrides in protocols.
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.
