Check for Embedded/normal Swift mismatches as part of module
validation, rather than after loading. Do this check as part of
canImport, so that canImport will evaluate false when there is a mismatch.
This will produce a warning in this case, because it's often a mistake
to have a module visible that isn't actually usable. However, don't
break the build over it.
Fixes#86419 / rdar://167851189
When building the `OSLog` module, look for a variable named
`osLogStringSectionName`. It must have a string literal as its
initializer, which provides the section name where the log strings
should be emitted. The `OSLog` module should contain something like
this:
let osLogStringSectionName = "__TEXT,__logit"
When not present, the compiler will default to
`__TEXT,__oslogstring,cstring_literals`, which was previously the
hardcoded section name. Now, OSLog can customize the name.
Implements rdar://171571056
Currently only the top level dependencies get serialized in Swift modules. In
practice this is not enough information to fully replay a module import
sequence, especially when the dependencies include binary SDK modules that were
built elsewhere. In this case we cannot follow the links to its depenencies,
since they refer to paths on a different machine or unavailable CAS. During an
EBM build, the dependency scanner writes the complete list of dependencies into
a json file called the explicit Swift module map -- including the local
locations of the dependencies of binary SDK modules. Using this LLDB can replay
a module import with 100% accuracy.
rdar://170514919
For clients, such as the debugger, who do not have access the full
output of the dependency scanner, it is a huger performance and
correctness improvement if each explicitly built Swift module not just
serialized all its Clang .pcm dependencies (via the serialized Clang
compiler invocation) but also its direct Swift module dependencies.
This patch changes the Swift module format to store the absolute path
or cas cache key for each dependency in the INPUT block, and makes
sure the deserialization makes these available to the ESML.
rdar://150969755
Introduce an experimental feature DeferredCodeGen, that defers the
generation of LLVM IR (and therefore object code) for all entities
within an Embedded Swift module unless they have explicitly requested
to not be emitted into the client (e.g., with
`@_neverEmitIntoClient`).
This feature is meant to generalize and subsume
-emit-empty-object-file, relying on lazy emission of entities rather
than abruptly ending the compilation pipeline before emitting any IR.
Part of rdar://158363967.
Ideally this would also update the `--version` output to be overridden
by `SWIFT_TOOLCHAIN_VERSION`, but unfortunately various tools rely on
the current format (eg. swift-build).
For now the semantics provided by `@extensible` keyword on per-enum
basis. We might return this as an upcoming feature in the future with
a way to opt-out.
Introduce a convenience for aborting while printing a given message
to a frame of the pretty stack trace. Use this in the existing places
where we're currently doing this.
An "abstract" ProtocolConformanceRef is a conformance of a type
parameter or archetype to a given protocol. Previously, we would only
store the protocol requirement itself---but not track the actual
conforming type, requiring clients of ProtocolConformanceRef to keep
track of this information separately.
Record the conforming type as part of an abstract ProtocolConformanceRef,
so that clients will be able to recover it later. This is handled by a uniqued
AbstractConformance structure, so that ProtocolConformanceRef itself stays one
pointer.
There remain a small number of places where we create an abstract
ProtocolConformanceRef with a null type. We'll want to chip away at
those and establish some stronger invariants on the abstract conformance
in the future.
When `ExtensibleEnums` flag is set, it's going to be reflected in
the module file produced by the compiler to make sure that consumers
know that non-`@frozen` enumerations can gain new cases in the
future and switching cannot be exhaustive.
Extend the module trace format with a field indicating whether a given
module, or any module it depends on, was compiled with strict memory
safety enabled. This separate output from the compiler can be used as
part of an audit to determine what parts of Swift programs are built
with strict memory safety checking enabled.
When serializing the module interface path of an interface that
is part of the SDK, we serialize relative to the SDK path. During
deserialization we need to know if a path was serialized relative
to the SDK or not. The existing logic assumes any relative path
has been serialized relative to the SDK, which makes it impossible
to compile modules from relative swiftinterface paths that are not
part of the SDK.
Update the swiftmodule file to include an attribute to show if the
path was serialized relative to the SDK or not, which is used
during deserialization to correctly reconstruct the interface path.
This change ensures that when loading some module dependency 'Bar' which has a package-only dependency on 'Foo', only the following clients attempt to resolve/load 'Foo':
- Source compilation with package-name equal to that of 'Bar'.
- Textual interface compilation of a *'package'* interface with package-name equal to that of 'Bar'.
Ensuring that the following kinds of clients do not attempt to resolve/load 'Foo':
- Source compilation with package-name different to that of 'Bar'
- Textual interface compilation of a public or private interface, regardless of package name.
This fixes the behavior where previously compilation of a Swift textual interface dependency 'X' from its public or private interface, with an interface-specified package-name, from a client without a matching package-name, resulted in a lookup of package-only dependencies of modules loaded into 'X'. This behavior is invalid if we are not building from the package textual interface, becuase the module dependency graph is defined by the package name of the source client, not individual module dependency package name. i.e. In-package module dependencies are resolved/loaded only if the parent source compile matches the package name.
Resolves rdar://139979180
Add flag `-load-resolved-plugin` to load macro plugin, which provides a
pre-resolved entry into PluginLoader so the plugins can be loaded based
on module name without searching the file system. The option is mainly
intended to be used by explicitly module build and the flag is supplied
by dependency scanner.
It might be unexpected to future users that `-swift-compiler-version`
would produce a version aligned to .swiftinterface instead of one used
to build the .swiftmodule file. To avoid this possible confusion, let's
scope down the version to `-interface-compiler-version` flag and
`SWIFT_INTERFACE_COMPILER_VERSION` option in the module.
Add function to handle all macro dependencies kinds in the scanner,
including taking care of the macro definitions in the module interface
for its client to use. The change involves:
* Encode the macro definition inside the binary module
* Resolve macro modules in the dependencies scanners, including those
declared inside the dependency modules.
* Propagate the macro defined from the direct dependencies to track
all the potentially available modules inside a module compilation.
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
This patch allows controlling the automatic import of private dependencies
separately from the DebuggerSupport option, which currently also triggers this
behavior. With explicit modules + precise compiler invocations LLDB is moving
towards no longer needing this behavior.
rdar://133088201
(cherry picked from commit a1ba7159e3)
When the dependency scanner picks a pre-built binary module candidate for a given dependency, it needs to be able to attempt to resolve its cross-import overlays relative to the textual interface that the binary module was built from. For example, if a collection of binary modules are located in, and resolved as dependencies from, a pre-built module directory, the scanner must lookup their corresponding cross-import overlays relative to the defining interface as read out from the binary module's MODULE_INTERFACE_PATH. https://github.com/swiftlang/swift/pull/70817 ensures that binary modules serialize the path to their defining textual interface.
Resolves rdar://130778577
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)
Doug Gregor
Arnold Schwaighofer
Adrian Prantl
Erik Eckstein
Artem Chikin
Ben Barham
Hamish Knight
Pavel Yaskevich
Saleem Abdulrasool
Richard Howell
Steven Wu
Pavel Yaskevich
swift-ci
Richard Howell
Alexis Laferrière
Egor Zhdan
Ellie Shin
Xi Ge
Tim Kientzle