Add a setting to IRGenOptions and key off of it to emit yield_once_2
coroutines using either (1) the same code-path as yield_once coroutines
or (2) a new, not-yet implemented code-path.
Add flags to set the value in both directions. During bringup, by
default, use the existing caller-allocated ABI.
Its functionality has been superseded by `@_spiOnly import`. There are no
longer any known clients and the flag was already unsupported in Swift 6, so
the functionality is now removed (but the flag is only deprecated for Swift 5).
Resolves rdar://136867210.
Use IncludeTreeFileList instead of full feature CASFS for swift
dependency filesystem. This allows smaller CAS based VFS that is smaller
and faster. This is enabled by the CAS enabled compilation does not
need to iterate file system.
rdar://136787368
When the frontend option `-abi-comments-in-module-interface` is provided
during interface printing, the printed interface will contain
additional comments that provide the mangled names for public symbols.
This is an experiment in seeing how much information we can
meaningfully extract from a printed Swift interface for the purpose of
bridging with other languages.
This commit adds new compiler options -no-warning-as-error/-warning-as-error which allows users to specify behavior for exact warnings and warning groups.
This PR ensures library-evolution is enabled for Package CMO; without it,
it previously fell back to regular CMO, which caused mismatching serialization
attributes if importing another module that had Package CMO enbaled, causing
an assert fail for loadable types.
Resolves rdar://135308288
Having package-name printed in public or private interface led to strange dependency errors in the past. For example, an SPI module is a dependency within a package, but due to the package-name being printed in public or private interface, dependency scanner tries to find it even for an external client of the package, causing a `no such module found` error. The -disable-print-package-name-for-non-package flag helps with such case, but to enforce the correct behavior, we should make it a default to not print package-name in public or private interface.
Resolves rdar://135260270
The old analysis pass doesn't take into account profile data, nor does
it consider post-dominance. It primarily dealt with _fastPath/_slowPath.
A block that is dominated by a cold block is itself cold. That's true
whether it's forwards or backwards dominance.
We can also consider a call to any `Never` returning function as a
cold-exit, though the block(s) leading up to that call may be executed
frequently because of concurrency. For now, I'm ignoring the concurrency
case and assuming it's cold. To make use of this "no return" prediction,
use the `-enable-noreturn-prediction` flag, which is currently off by
default.
Adds sections `__TEXT,__swift_as_entry`, and `__TEXT,__swift_as_ret` that
contain relative pointers to async functlets modelling async function entries,
and function returns, respectively.
Emission of the sections can be trigger with the frontend option
`-Xfrontend -enable-async-frame-push-pop-metadata`.
This is done by:
* IRGen adding a `async_entry` function attribute to async functions.
* LLVM's coroutine splitting identifying continuation funclets that
model the return from an async function call by adding the function
attribute `async_ret`. (see #llvm-project/pull/9204)
* An LLVM pass that keys off these two function attribute and emits the
metadata into the above mention sections.
rdar://134460666
During the lifecycle of a feature, it may start as an experimental feature and
then graduate to become an upcoming feature. To preserve compatibility with
projects that adopted the feature when it was experimental,
`-enable-experimental-feature` ought to be able to enable upcoming features,
too.
Since projects may use `-enable-experimental-feature` for compatibility with an
older toolchain that does not have the feature as an upcoming feature, there is
no warning when the flag is used to enable an upcoming feature.
Note that if the semantics of a feature change when it graduates from
experimental to upcoming, then the feature must be renamed so that projects
using the experimental feature have an opportunity opt-in to the new semantics
of the upcoming feature.
Resolves rdar://134276783.
This makes sure that Swift respects `-Xcc -stdlib=libc++` flags.
Clang already has existing logic to discover the system-wide libc++ installation on Linux. We rely on that logic here.
Importing a Swift module that was built with a different C++ stdlib is not supported and emits an error.
The Cxx module can be imported when compiling with any C++ stdlib. The synthesized conformances, e.g. to CxxRandomAccessCollection also work. However, CxxStdlib currently cannot be imported when compiling with libc++, since on Linux it refers to symbols from libstdc++ which have different mangled names in libc++.
rdar://118357548 / https://github.com/swiftlang/swift/issues/69825
The code that generates the runtime path is not right for Windows;
fix it to point at the correct place.
This makes simple use of `swift test.swift` work.
rdar://132598892
As-is, this default interferes with the incremental build machinery which conservatively assumes that binary module dependencies must cause dependents to be re-built.
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.
Add support for swift style diagnostics for swift caching. This includes
pre-populate the GeneratedSourceInfo with macro name so it doesn't need
to infer from an ASTNode, which the caching mechanism cannot preserve.
Still leave the default diagnostic style to LLVM style because replaying
swift style diagnostics is still very slow and including parsing source
file using swift-syntax.
rdar://128615572
There are two axes on which a saved frontend flag can be categorized for
printing in a `.swiftinterface` file:
1. Whether the flag is "ignorable" or not.
2. Which levels of interface the flag should be in (public, package).
This refactor ensures that those two axes are modeled independently and
prepares the infrastructure to allow flags to appear in the private and package
interfaces without being included in the public interface.
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
