Make sure ClangExtraArgs are inherited in the subinstance for module
lookup/building when direct cc1 mode is used. This is useful for lldb,
which does a slight different variant of the explicit module build
that do not have swift-driver cooridination and replies on the
subInstance to load swiftmodule. When such configuration is used, if
DirectCC1 compile option is inherited without any extra cc1 arguments,
the clang importer inside the sub-instance is actually malformed,
causing the swift instance failed to be created.
rdar://135611011
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 fixes the debugger's ability to perform expression evaluation when debugging an
executable that was built with both under the following circumstances:
1. explicit module build
2. `-application-extension`
The fix is to include `-fapplication-extension` as an XCC field in the swiftmodule.
This primes the debugger's ClangImporter with the correct flag needed to load the
explicitly built pcm files generated at build time.
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
Skip aliasing Foundation when `-alias-module-names-in-module-interface` is
specified since it appears to confuse the typechecker. The module name
"Foundation" is hardcoded and checked in several places, so aliasing Foundation
may be changing some subtle behaviors.
Resolves rdar://128897610.
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
Use a stricter module hash for modules as moving towards more explicit
modules. Previously, a normalized target triple without deployment
target is used as part of the module hash, with the assumption that
deployment target should not change binary module generated.
In reality, the binary module compilation also needs to provide the
typecheck for all interface to ensure the underlying C/ObjC module that
built with the correct deployment target does provide the interfaces to
pass typecheck. Using a stricter module hash can avoid the potentially
confusing error when importing the module.
This commit adds following to module hash to distinguish swiftmodules.
* Deployment target
* -application-extension
rdar://134301179
Fix a bug that swift clang importer is not setup correctly when prefix
map is used. There are two separate issues:
* CC1 args used to setup clang import when building swift (interface and
sources) are not correctly remapped.
* When loading SDKInfo from SDK path, the SDKSettings.json is not
loading from VFS, thus the file cannot be loaded from remapped path.
rdar://134458611
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.
When direct cc1 mode is used, the cc1 arguments are generated from extra
clang targets so there is no need to add this extra argument.
Furthermore, the `--target=` is a clang driver argument and is not valid
under cc1 mode.
Needed for: rdar://134090397
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
