When building .swiftmodule from .swiftinterface,
`disable-experimental-parser-round-trip` should be applied if the
interface file with build with the flag.
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 flag was added back in 2020, but it didn't function properly, since a lot of other code in the compiler assumed the platform-default C++ stdlib until recently (https://github.com/swiftlang/swift/pull/75589).
The recommended way to use a non-default C++ stdlib in Swift now is to pass `-Xcc -stdlib=xyz` argument to the compiler.
This change removes the `-experimental-cxx-stdlib` flag.
Introduce the concept of public facing module name designed to hide support module from external clients. This name should be set on a support module that is an implementation detail of a public module, the public module name of the support module should be the name of the public module. For example, BigKitCore’s public module name can be set to BigKit for diagnostics to refer to both modules as BigKit.
This name is used to refer to the support module in diagnostics for external clients. We determine if a client is external if they also import the module identified by the public module name. If a client doesn’t import the public module, diagnostics will always use the real name of the module.
The public module name is set with the flag -public-module-name and it's preserved in textual swiftinterfaces and binary swiftmodules.
rdar://134527933
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
This flag will be used to have the driver print out all possible paths to the argument dependency module name. `-explain-module-dependency` will print the first discovered such path, in order to produce an answer sooner.
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 is necessary to ensure that availability checks contained in inlined
functions are compiled correctly for zippered modules when built from
interface.
Resolves rdar://130094532.
