This introduces a secondary flag `-sysroot` for the non-Darwin targets,
primarily Unicies. The intention here is to support a split `-sdk`,
`-sysroot` model where the `-sdk` parameter provides the Swift "SDK"
which augments the native platform's C sysroot which is indicated as
`-sysroot`. For the case of Android, this would allow us to provide a
path to the NDK sysroot and the Swift SDK allowing us to cross-compile
Android binaries from Windows.
Having package-name flag in non-package interfaces causes them to be built as if
belonging to a package, which causes an issue for a loading client outside of the
package as follows.
For example, when building X that depends on A with the following dependency chain:
X --> A --> B --(package-only)--> C
1. X itself is not in the same package as A, B, and C.
2. When dependency scanning X, and opening up B, because the scan target is in a
different package domain, the scanner decides that B's package-only dependency
on C is to be ignored.
3. When then finally building A itself, it will load its dependencies, but because
the .private.swiftinterface of A still specifies -package-name, when it loads
B, it will then examine its dependencies and deem that this package-only dependency
on C is required.
Because (2) and (3) disagree, we get an error now when building the private A textual interface.
rdar://130701866
Now that API descriptions are emitted during module build jobs when
`-emit-api-descriptor-path` is specified and the build system has been updated
to pass that flag when the output is needed, the `swift-api-extract` frontend
alias is no longer used. Delete it and the tests that were specific to invoking
`swift-api-extract`.
Resolves rdar://116537394.
Separate swift-syntax libs for the compiler and for the library plugins.
Compiler communicates with library plugins using serialized messages
just like executable plugins.
* `lib/swift/host/compiler/lib_Compiler*.dylib`(`lib/CompilerSwiftSyntax`):
swift-syntax libraries for compiler. Library evolution is disabled.
* Compiler (`ASTGen` and `swiftIDEUtilsBridging`) only depends on
`lib/swift/host/compiler` libraries.
* `SwiftInProcPluginServer`: In-process plugin server shared library.
This has one `swift_inproc_plugins_handle_message` entry point that
receives a message and return the response.
* In the compiler
* Add `-in-process-plugin-server-path` front-end option, which specifies
the `SwiftInProcPluginServer` shared library path.
* Remove `LoadedLibraryPlugin`, because all library plugins are managed
by `SwiftInProcPluginServer`
* Introduce abstract `CompilerPlugin` class that has 2 subclasses:
* `LoadedExecutablePlugin` existing class that represents an
executable plugin
* `InProcessPlugins` wraps `dlopen`ed `SwiftInProcPluginServer`
* Unified the code path in `TypeCheckMacros.cpp` and `ASTGen`, the
difference between executable plugins and library plugins are now
abstracted by `CompilerPlugin`
Updates swift-symbolgraph-extract to parse "-cxx-interoperability-mode"
flags and update the underlying compiler invocation. This fixes a bug
where were are unable to extract the symbol graph from swiftmodules with
transitive cxx modules because we parsed cxx headers as c headers.
rdar://128888548 (Add support for parsing cxx headers)
the blocklist mechanism supports using project name as a key for specific actions.
We usually retrieve that name via other means such as querying env vars, which isn't CAS friendly.
Instead, we should pass the ownining project name down to the compiler via a formal compiler
argument.
This adds three new assertion macros:
* `ASSERT` - always compiled in, always checked
* `CONDITIONAL_ASSERT` - always compiled in, checked whenever the `-compiler-assertions` flag is provided
* `DEBUG_ASSERT` - only compiled into debug builds, always checked when compiled in (functionally the same as Standard C `assert`)
The new `-compiler-assertions` flag is recognized by both `swift-frontend` and
`swiftc`.
The goal is to eventually replace every use of `assert` in the compiler with one of the above:
* Most assertions will use `ASSERT` (most assertions should always be present and checked, even in release builds)
* Expensive assertions can use `CONDITIONAL_ASSERT` to be suppressed by default
* A few very expensive and/or brittle assertions can use `DEBUG_ASSERT` to be compiled out of release builds
This should:
* Improve quality by catching errors earlier,
* Accelerate compiler triage and debugging by providing more accurate crash dumps by default, and
* Allow compiler engineers and end users alike to add `-compiler-assertions` to get more accurate failure diagnostics with any compiler
This change is two fold. Firstly it enables collection of exported
imports from non source file units. Additionally this recurses through
the exported imports to ensure the transitive set is collected.
Fixes https://github.com/apple/swift/issues/59920
rdar://89687175
* Add a new flag -experimental-package-cmo that requires -experimental-allow-non-resilient-access.
* Support serializing package decls for CMO in package if enabled.
* Only applies to default mode CMO.
* Unlike the existing CMO, package CMO can be built with -enable-library-evolution as package
modules are required to be built together in the same project.
* Create hasPublicOrPackageVisibility to opt in for package decls; needed for CMO, SILVerifier,
and other call sites that verify or determine codegen.
Resolves rdar://121976014
Add an experimental option to tell dependency scanner to report clang
cc1 args should be used to construct clang importer in all constructed
swift-frontend tasks.
Model indexing output as an optional output from the swift compiler
as the build system has no knowledge about them and they can be
regenerated by indexer. Make sure the indexing store output is produced
when cache hit so the compilation is done for the module. If cache hit,
no indexing data is produced since no compilation is done.
rdar://123331335
we only check if the loaded module is built from a package interface. This is
not enough as a binary module could just contain exportable decls if built with
experimental-skip-non-exportable-decls, essentially resulting in content equivalent
to interface content. This might be made a default behavior so this PR requires
a module to opt in to allow non-resilient access by a participating client in the
same package.
Since it affects module format, SWIFTMODULE_VERSION_MINOR is updated.
rdar://123651270
When `-enable-lazy-typecheck` is specified, serialization may be expected to
run on an AST containing invalid declarations since type checking may happen
on-demand, during serialization, in this mode. If the declarations that are
invalid are not skipped, then the compiler is likely to crash when attempting
to serialize them. Now, invalid declarations are skipped and an error is
emitted at the end of serialization to note that serialization failed.
Additionally, a new `-Rmodule-serialization` flag can be specified to request
more detailed information about module serialization failures. This would be
useful in a situation where lazy typechecking does not produce any diagnostic
for some reason, but module serialization fails and more information is
therefore required to debug.
Resolves rdar://123260476
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
Add a `-min-runtime-version` option that can be used to avoid problems
when building on Linux and Windows where because the runtime isn't
part of the OS, availability doesn't solve the problem of trying to
build the compiler against an older runtime.
Also add functions to IRGen to make it easy to test feature
availability using both the runtime version and the existing Darwin
availability support.
rdar://121522431
Obsolete the `-enable-swift3-objc-inference` option and related options by
removing support for inferring `@objc` attributes using Swift 3 rules.
Automated migration from Swift 3 has not been supported by the compiler for
many years.
The compiler has not supported migrating Swift 3 code to Swift 4 for a long
time. The `-enable-swift3-objc-inference` option and related options were
originally designed to aid that transition and should be deprecated at this
point.
Resolves rdar://120490061
`frontend-parseable-output` related options only affects diagnostics and
should be cache invariant. This also fixes the bug that xcbuild can
sometimes modify this argument from execution pipeline, causing cache
key to change.
rdar://120552768
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
`-disable-sandbox` to disable sandboxing when invoking subprocess from
from the frontend. Since `sandbox(7)` in macOS doesn't support nested
sandbox, complation used to fail when the parent build process is sandboxed.
Add a new flag to enable package interface loading.
Use the last value of package-name in case of dupes.
Rename PrintInterfaceContentMode as InterfaceMode.
Update diagnostics.
Test package interface loading with various scenarios.
Test duplicate package-name.
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.
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.
Update swift cache key computation mechanism from one cache key per
output, to one cache key per primary input file (for all outputs that
associated with that input).
The new schema allows fewer cache lookups while still preserving most of
the flexibility for batch mode and incremental mode.
