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
canImport should be able to take an additional parameter labeled by either version or
underlyingVersion. We need underlyingVersion for clang modules with Swift overlays because they
have separate version numbers. The library users are usually interested in checking the importability
of the underlying clang module instead of its Swift overlay.
Part of rdar://73992299
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>
.swiftsourceinfo contains comment ranges, so parsing should attach
comments when it is being emitted. Generally this turned out to be fine
because .swiftdoc is usually output as well, but when calling
swift-frontend directly in tests that isn't necessarily the case.
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
Introduce flags `-enable-actor-data-race-checks` and
`-disable-actor-data-race-checks` to enable/disable emission of code
that checks that we are on the correct actor. Default to `false` for
now but make it easy to enable in the future.
Intro the concept of library access or distribution level to identify
layers of libraries and report public imports of private libraries from
public ones.
rdar://62934005
Previously, when the standard library module interface was broken, Swift would try to rebuild it repeatedly during -compile-module-from-interface jobs because `ASTContext::getStdlibModule()` would try to load the standard library again each time it was called. This led to extremely slow compilations that repeatedly emitted the same errors.
To avoid this, we make ModuleInterfaceBuilder try to load the standard library right away and bail out if it can’t.
Fixes rdar://75669548.
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.
