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.
Introduces the -name-bind frontend action that is intended as an intermediary between the parse-only actions and a full typechecking pass. In this phase, module imports will be validated and resolved, making it possible to emit full make-style dependencies files among other things.
Note that all information available to a parse-only pass is available to name binding, but because it does not continue-on to typecheck input files, full semantic information is not.
This flag is based on Clang's -fdebug-prefix-map, which lets the user remap absolute paths in debug info. This is necessary for reproducible builds and allows debugging to work on a different machine than the one that built the code when paths to the source may be different.
This was retained to help ease migration between versions of the 4.2 compiler
between when the flag was originally introduced and the full fix landed. It's
not longer needed and there's no reason to retain it in the full release.
Fixes rdar://problem/40502379.
This work-around is no longer needed now that the full fix landed in
https://github.com/apple/swift/pull/16615. The argument is left with a warning
to help with migration between compilers with the work-around and compilers with
the full fix (see also rdar://problem/40502379).
Fixes rdar://problem/40476573.
IRGen can introduce calls to type metadata accessors for types that
should not be visible to the current translate, which can manifest in
linker errors within a module (for references to private types when
whole module optimization is disabled) or across modules (for
references to private/internal types in another module). Introduce a
new compiler flag `-emit-public-type-metadata-accessors` that emits
all type metadata accessors with public linkage, to work around the
problem in affected projects. This flag is intended to go away once we
have a proper solution.
This bug has been around in Swift "forever", but compiling the
overlays using -enable-resilience has exacerbated the problem and
caused regressions. This is a short-term fix to
rdar://problem/40229755 while we work on the correct long-term fix.
