By default package decls are treated as resilient, similar to public (non-frozen).
This PR adds support to allow direct access to package decls at use site if opted-in.
Requires the loaded module to be a binary module in the same package.
Resolves rdar://121626315
The flag -no-verify-emitted-module-interface tells the driver to skip
verifying the swiftinterfaces emitted by the compiler. It used to be
passed only to the driver.
Let's pass it down to the frontend as well and write it in the
swiftinterfaces. This will help understand them from the reader side.
This patch adds a new flag sanitize-stable-abi to support linking
against the Sanitizers stable ABI added recently in compiler-rt. The
patch also passes extra options for the ASan pass when using this flag
to outline instrumentation code and remove version check.
rdar://112915278
It has an extension .package.swiftinterface and contains package decls
as well as SPIs and public/inlinable decls. When a module is loaded
from interface, it now looks up the package-name in the interface
and checks if the importer is in the same package. If so, it uses
that package interface found to load the module. If not, uses the existing
logic to load modules.
Resolves rdar://104617854
The current implementation of `-application-extension` has a problem that affects the generation of ObjC headers for regular Swift modules.
The primary purpose of `-application-extension` is to prevent the use of unavailable APIs in app extensions. However, it has an impact on the generation of -Swift.h headers and exposes Swift's internal declarations to ObjC. This behavior is appropriate for mixed modules that are not consumed externally, such as app extensions, but it fails to address the situation when a module is not an extension itself but is consumed by the extension (c90cd11).
To resolve this issue while maintaining the desired behavior, we can introduce a new flag for this particular use-case.
Extend function type metadata with an entry for the thrown error type,
so that thrown error types are represented at runtime as well. Note
that this required the introduction of "extended" function type
flags into function type metadata, because we would have used the last
bit. Do so, and define one extended flag bit as representing typed
throws.
Add `swift_getExtendedFunctionTypeMetadata` to the runtime to build
function types that have the extended flags and a thrown error type.
Teach IR generation to call this function to form the metadata, when
appropriate.
Introduce all of the runtime mangling/demangling support needed for
thrown error types.
Previously it was hardcoded to version 4 on all platforms.
This patch introduces a driver and frontend option -dwarf-version to configure it if needed.
An "API descriptor" file is JSON describing the externally accessible symbols
of a module and metadata associated with those symbols like availability and
SPI status. This output was previously only generated by the
`swift-api-extract` alias of `swift-frontend`, which is desgined to take an
already built module as input. Post-processing a built module to extract this
information is inefficient because the module and the module's dependencies
need to be deserialized in order to visit the entire AST. We can generate this
output more efficiently as a supplementary output of the -emit-module job that
originally produced the module (since the AST is already available in-memory).
The -emit-api-descriptor flag can be used to request this output.
This change lays the groundwork by introducing frontend flags. Follow up
changes are needed to make API descriptor emission during -emit-module
functional.
Part of rdar://110916764.
The plugin layouts are different across platforms. Move this into a
virtual method and allow replacement. On Windows, the plugins are
placed into the `bin` directory as the DLLs should always be co-located
to ensure that the proper DLLs are found (there is no concept of RPATH).
This action is currently just an alias of the `-resolve-imports` action.
However, it's named to more clearly reflect the purpose which is to do the
minimal typechecking needed in order to emit the requested outputs. This mode
is intended to improve performance when emitting `.swiftinterface` and `.tbd`
files.
When `-warn-on-potentially-unavailable-enum-case` was introduced, the build
system was required to invoke `swift-frontend` at artificially low deployment
targets when emitting `.swiftinterface` files for legacy architectures. Because
the deployment target was low, some availability diagnostics needed to be
de-fanged in order to allow module interface emission to succeed. Today, the
build system is able to use the correct deployment target when emitting module
interfaces and the `-warn-on-potentially-unavailable-enum-case` is superfluous,
so deprecate it.
Resolves rdar://114092047
Also, make the analogous change to apple/swift-driver#1372, which gets the
sanitizer tests working on Android again, and remove the lld_lto feature in the
tests, which is now unused.
To avoid having duplicated macro implementations in both the device and
simulator platforms, when building for a simulator platform, pass
`-external-plugin-path` that points into the *device* platform. There
is no need to have macro implementations in the simulator platforms.
Implements rdar://112563655.
LLVM deprecated, renamed, and removed a bunch of APIs. This patch
contains a lot of the changes needed to deal with that.
The SetVector type changed the template parameters.
APInt updated multiple names, countPopulation became popcount,
getAllOnesValue became getAllOnes, getNullValue became getZero, etc...
Clang type nullability check stopped taking a clang AST context.
The LLVM IRGen Function type stopped exposing basic block list directly,
but gained enough API surface that the translation isn't too bad.
(GenControl.cpp, LLVMMergeFunctions.cpp)
llvm::Optional had a transform function. That was being used in a couple
of places, so I've added a new implementation under STLExtras that
transforms valid optionals, otherwise it returns nullopt.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
'load-plugin-library', 'load-plugin-executable', '-plugin-path' and
'-external-plugin-path' should be searched in the order they are
specified in the arguments.
Previously, for example '-plugin-path' used to precede
'-external-plugin-path' regardless of the position in the arguments.
The toolchain was introduced in 710816d3e0
but was not used. Test cases now use fake resource dir to lookup
static-executable-args.lnk file, which is required by the toolchain but
is not present when not building stdlib for WASI.
The swift driver emits extra newlines because it applies the LF ->
CRLF conversions again on the outpt from the child processes. Fix it
by using the binary mode when outputting the output from the child
processes.
Fixes: #64413
When the current toolchain is not a Xcode toolchain, derive
'-external-plugin-path' poinintng Xcode plugins paths, so we can use
plugins in Xcode.
rdar://108624128
