This mechanism allows the compiler to use a backup interface file to build into a binary module when
a corresponding interface file from the SDK is failing for whatever reasons. This mechansim should be entirely opaque
to end users except several diagnostic messages communicating backup interfaces are used.
Part of rdar://77676064
If the `-static` option is specified, store that in the generated
swiftmodule file. When de-serializing, recover this information in the
representative SILModule.
This will be used for code generation on Windows. It is the missing
piece to allow static linking to function properly. It additionally
opens the path to additional optimization on ELF-ish targets - GOT, PLT
references can be avoided when the linked module is known to be static.
Co-authored by: Saleem Abdulrasool <compnerd@compnerd.org>
This allows library authors to pass down a project version number so that library users can conditionally
import that library based on the available version in the search paths.
Needed for rdar://73992299
Tests are written under the assumption that since they are conditioned
on the concurrency feature, the explicit `_Concurrency` module import is
not necessary since it is imported implicitly if concurrency is enabled.
However, this is not the case; the module import is only included
implictly on selected targets.
It may very well be ideal to import the `_Concurrency` module implicitly
when `SWIFT_ENABLE_EXPERIMENTAL_CONCURRENCY` is true and therefore solve
the incorrect assumption, however, that decision is something that is
above my pay grade. Some guidance on this is welcome.
That being said, on OpenBSD, Dispatch is currently unsupported upstream
but there is a draft PR to add this support (559). This means that even
while we have draft Dispatch support, all the Concurrency tests fail
because they do not import `_Concurrency`, but we cannot unconditionally
support concurrency until Dispatch is supported upstream.
Therefore, we especially need to support both cases. So instead, on
OpenBSD, if the concurrency feature is enabled, import the module
implicitly, otherwise, do not. This lets us run the tests and get a good
signal that concurrency features are working with the draft Dispatch
support, while avoiding problems when building with the documented
configuration that disables Dispatch, and therefore, disables
concurrency.
In case the compiler is used with concurrency features enabled (by-default or otherwise), and an older SDK is used which does not include the `_Concurrency` module, do not load this module implicitly. Instead, emit a diagnostic indicating that no such module is found.
rdar://76967260
This commit fixes two weird bugs in -verify mode:
1. SourceLocs from the wrong SourceManager could be passed through a ForwardingDiagnosticConsumer into the DiagnosticVerifier.
2. -verify-additional-file did not error out correctly when the file couldn’t be opened.
No tests, as we only have basic tests for the diagnostic verifier.
This will enable users to try out the '-enable-ossa-modules' flag if their
compiler supports it and get OSSA code on all inlinable code that they use. The
idea is that this is a nice way to stage this in and get more testing.
The specific implementation is that the module interface loader:
1. Knows if enable ossa modules is enabled not to search for any compiled
modules. We always rebuild from the interface file on the system.
2. Knows that if enable ossa modules is enabled to mixin a bit into the module
interface loader cache hash to ensure that we consider the specialized ossa
compiled modules to be different than the modules in that cache from the system.
This ensures that when said flag is enabled, the user transparently gets all
their code in OSSA form from transparent libraries.
Introduce a new compiler flag `-module-abi-name <name>` that uses the
given name as the ABI name for the module (rather than the module's
name in source code). The ABI name impacts name mangling and metadata.
In the legacy driver, these flags will merely be propagated to the
frontends to indicate that they should disable serialization of
incremental information in swift module files.
In the new driver, these flags control whether the Swift driver performs
an incremental build that is aware of metadata embedded in the module.
Kudos to David for coming up with our new marketing name: Incremental
Imports.
rdar://74363450
The LLVM rebranch added an “AllowUnknownKeys” setting to llvm::yaml::Input, which lets us rip out a lot of marginal code and encourages a broader rework of access note error diagnosis:
• Access note warnings and errors are now diagnosed as they’re found during YAML parsing
• They now have proper SourceLocs inside the .accessnotes file
• They’re now tested using -verify-additional-file instead of FileCheck
• A lot of gross duct tape is now gone
LLVM’s YAML support wants to show a hard error if an unknown string appears in an access note. Instead, emit a remark but load the parts of the access note we do understand to allow for future expansion of access notes.
This option allows the compiler to retry opening an input file if the previous
opening returns an error of bad file descriptor. Swift-driver will set this
argument in certain circumstances to walk-around such error.
rdar://73157185
This change adds a frontend flag, -verify-additional-file, which can be used to pass extra files directly to the diagnostic verifier. These files are not otherwise considered to be Swift source files; they are not compiled or even properly parsed.
This feature can be used to verify diagnostics emitted in non-source files, such as in module interfaces or header files.
It is now the responsibility of the scanDependencies code to instantiate (and share) the cache.
e.g. FrontendTool instantiates a new cache per `-scan-dependencies` invocation, and the DependencyScanningTool keeps one shared cache across its lifetime.
Also, continue trying opening files even if any of primary files are
missing so that the caller can know all files failed to open.
rdar://problem/33757793
This will allow individual module scans in batch-scanning mode to share the already-scanned Swift and Clang modules, and avoid instantiating a brand new Clang `DependencyScanningService` for each batch entry.
Performance-improvement anecdote:
A simple experiment which performs a batch scan of all modules involved in planning a build of SwiftPM (using SwiftPM in explicit module build mode), which includes 126 batch entries (scan entry-points), with 21 distinct Swift modules and 27 distinct Clang modules (many Clang modules are scanned multiple times, at different target versions), this modification reduces the total time taken from ~34 seconds to ~6.
