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.
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
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`
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
