When '.package.swiftinterface' loading ('-experimental-package-interface-load') is disabled and when '-scanner-module-validation' is disabled, the scanner defaults to locating the non-package textual interface and may specify its adjacent binary module as a valid candidate binary module to use. If said candidate is up-to-date and ends up getting used, and belongs to the same package as the loading Swift source, then the source compilation may attempt to load its package-only dependencies. Since the scanner only parsed the non-package textual interface, those dependencies are not located and specified as inputs to compilation. This change causes the scanner, in such cases, to also lookup package-only dependencies in adjacent binary Swift modules of textual Swift module dependencies, if such dependency belongs to the same package as the source target being scanned.
Resolves rdar://135215789
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)
As-is, this default interferes with the incremental build machinery which conservatively assumes that binary module dependencies must cause dependents to be re-built.
Add a check for the client side flag which explcitly opts in to loading the package interface,
besides whether package-name is empty or in the same package.
rdar://131393508
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
Fix the problem that when the only module can be found is an
invalid/out-of-date swift binary module, canImport and import statement
can have different view for if the module can be imported or not.
Now canImport will evaluate to false if the only module can be found for
name is an invalid swiftmodule, with a warning with the path to the
module so users will not be surprised by such behavior.
rdar://128876895
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)
This change modifies the dependency scanner to keep track of source locations of each encountered 'import' statement, in order to be able to emit diagnostics with source locations if an import failed to resolve.
- Keep track of each 'import' statement's source buffer, line number, and column number when adding it. The dependency scanner utilizes separate compilation instances, and therefore separate Source Managers for scanning `import` statements of user sources and textual interfaces of Swift dependencies. Since import resolution may happen in the main scanner compilation instance while the `import` itself was found by an interface-scanning sub-instance, we cannot simply hold on to the import's `SourceLoc`.
- Add libSwiftScan API for diagnostics to carry above source locations to clients.
We cannot always rely on being able to do so only as an overlay query upon loading 'requires cplusplus' modulemap modules. The 'requires' statement only applies to submodules, and we may not be able to query language feature modulemap attributes in dependency scanning context.
When swift dependency scanner first finds a binary module for a testable
import, verify if the module is built for enable-testing or not. If not,
keeps searching in case there is a second testable binary module in the
search path.
Previously, the first binary module will always be accepted by scanner
and rely on the importer to provide a good diagnostics. Now the scanner
will emit a warning before continue searching, so user understands why
the binary in the search path is not taken.
SILOptions::EnableSerializePackage info is lost.
SILVerifier needs this info to determine whether resilience
can be bypassed for decls serialized in a resiliently
built module when Package CMO optimization enabled.
This PR adds SerializePackageEnabled bit to Module format
and uses that in SILVerifier.
Resolves rdar://126157356
If a testable module is loaded from a non-testable import, ignore its
optional dependencies because the consumer should not use them. This
matches the behavior of the implicit build or the behavior how
forwarding module is created.
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Follow-up adjustment for binary module selection in dependency scanning
time. If a testable binary module doesn't have an interface file, it
should be used even it might pull in more dependencies.
Teach scanner to pick and choose binary modules correctly based on if it
is testable import or not. Some situations that scanner need to be
careful when testable is involved:
* When it is a regular import, it should not import binary modules that
are built with -enable-testing, it should prefer interfaces if that is
available.
* When testable import, it should only load binary module and it should
make sure the internal imports from binary modules are actually
required for testable import to work.
If a testable import only find a regular binary module, dependency
scanner currently will just preceed with such module and leave the
diagnostics to swift-frontend, because the alternative (failed to find
module) can be confusing to users.
rdar://125914165
Improve swift dependency scanner by validating and selecting dependency
module into scanner. This provides benefits that:
* Build system does not need to schedule interface compilation task if
the candidate module is picked, it can just use the candidate module
directly.
* There is no need for forwarding module in the explicit module build.
Since the build system is coordinating the build, there is no need for
the forwarding module in the module cache to avoid duplicated work,
* This also correctly supports all the module loading modes in the
dependency scanner.
This is achieved by only adding validate and up-to-date binary module as
the candidate module for swift interface module dependency. This allows
caching build to construct the correct dependency in the CAS. If there
is a candidate module for the interface module, dependency scanner will
return a binary module dependency in the dependency graph.
The legacy behavior is mostly preserved with a hidden frontend flag
`-no-scanner-module-validation`, while the scanner output is mostly
interchangeable with new scanner behavior with `prefer-interface` module
loading mode except the candidate module will not be returned.
rdar://123711823
In certain cases (e.g. using arm64e interface to build arm64 target),
the target needs to be updated when building swiftinterface. Push the
target overwrite as early as possible to swiftinterface parsing by
providing a preferred target to relevant functions. In such cases, the
wrong target is never observed by other functions to avoid errors like
the sub-invocation was partially setup for the wrong target.
Otherwise they may have module dependencies of their own which will not be detected by the scanner and included in the list of explicit inputs for compilation.
we only check if the loaded module is built from a package interface. This is
not enough as a binary module could just contain exportable decls if built with
experimental-skip-non-exportable-decls, essentially resulting in content equivalent
to interface content. This might be made a default behavior so this PR requires
a module to opt in to allow non-resilient access by a participating client in the
same package.
Since it affects module format, SWIFTMODULE_VERSION_MINOR is updated.
rdar://123651270
There are scenarios where different compilers are distributed with
compatible serialization format versions and the same tag. Distinguish
swiftmodules in such a case by assigning them to different distribution
channels. A compiler expecting a specific channel will only read
swiftmodules from the same channel. The channels should be defined by
downstream code as it is by definition vendor specific.
For development, a no-channel compiler loads or defining the env var
SWIFT_IGNORE_SWIFTMODULE_REVISION skips this new check.
rdar://123731777
When scanning finds a dependency in the same package, do not load
public/private swiftinterface since they do not have the package level
decl to compile the current module. Always prefer package module (if
enabled), or use binary module, unless it is building a public/private
swiftinterface file in which case the interface file is preferred.
This also does some clean up to sync up the code path between implicit
and explicit module finding path.
rdar://122356964
Fix a use-after-free bug in package-name extraction code, where the
BumpPtrAllcoator is destroyed before a StringRef that uses the allocated
name is used.
When a NoncopyableGenericsMismatch happens between the compiler and
stdlib, allow the compiler to rebuild the stdlib from its interface
instead of exiting with an error.
By populating the memory cache before loading the module, we can avoid a cycle
where a module is imported that is an overlay, which then triggers
ClangImporter, which then (redundantly) triggers the import of the overlay
module, which would reimport the module again, since it's import is still
underway and it hasn't been entered into the cache yet.
rdar://118846313
A swiftmodule can only be correctly ingested by a compiler
that has a matching state of using or not-using
NoncopyableGenerics.
The reason for this is fundamental: the absence of a Copyable
conformance in the swiftmodule indicates that a type is
noncopyable. Thus, if a compiler with NoncopyableGenerics
reads a swiftmodule that was not compiled with that feature,
it will think every type in that module is noncopyable.
Similarly, if a compiler with NoncopyableGenerics produces a
swiftmodule, there will be Copyable requirements on each
generic parameter that the compiler without the feature will
become confused about.
The solution here is to trigger a module mismatch, so that
the compiler re-generates the swiftmodule file using the
swiftinterface, which has been kept compatible with the compiler
regardless of whether the feature is enabled.
This is a new attempt at a reexport feature for SPI decls. The previous
behavior was to reexport SPIs only between modules with both `@_exported` and
an export-as relationship. The limitation on export-as turned out to be too
restrictive in some cases.
We may be tempted to reexport SPIs through all exported imports. However,
the exported imports are very common between clang module and it can lead
to surprises if dependencies between clang modules end up exporting SPIs from
unexpected modules.
As a middle ground, reexport SPI only through Swift `@_exported` dependencies,
and not through clang reexports. While this is a new distinction between Swift
and clang dependencies, I believe it provides the expected behavior and
the result is more straightforward than the current logic.
rdar://115901208
This reverts commit 3cc2831608.
The compiler's revision check has been relaxed since the feature was introduced
and so it's nos better to reduce the number of special code paths for LLDB in
the compiler to facilitate reasoning about it.
rdar://117824367
