Relying on the corresponding field in the '-explicit-swift-module-map-file' provided by the driver.
Only bridging headers require a module map because that's what aids header include resolution. With lazy module loading today, '.modulemap' parsing which happens when instantiating Clang is responsible for associating headers with modules. Then upon encountering a header include inside the bridging header the compiler knows which module corresponds to said header and is then able to load explicitly-provided PCM for that module. For all other module dependencies, they are only ever queried by-name from Swift, so '.modulemap' parsing is not necessary.
To preserve compatibility with older compilers that do not allow `IsolatedAny`
to be enabled in production compilers, use an alias experimental feature when
building the stdlib (`IsolatedAny2`).
Also, add `@_allowFeatureSuppression(IsolatedAny)` in a couple spots it was
forgotten.
Partially resolves rdar://125138945
The `.swiftinterface` of the standard library must remain compatible with some
older compilers. Unfortunately, some of those older compilers do not allow the
experimental feature `NoncopyableGenerics` to be enabled in production. To
allow the stdlib to build with non-copyable generics enabled and still have the
older compilers consume its interface, we have to use a new experimental
feature identifier that they do not know about.
Partially resolves rdar://125138945
When building a module from its interface, do not diagnose whether or not a
feature is available in production compilers. This is important since older
compilers may be expected to build .swiftinterfaces that were produced by newer
compilers where the feature has been enabled by default.
Resolves rdar://125500318
When direct-cc1 scanning mode is enabled, do not inherit -Xcc options
from the commandline as those are driver flags and clang importer
already handle the conversion.
rdar://125194535
Assign the path returned from dependency scanner for the module to the
buffer identifier when loading modules from CAS. This fixes a warning in
module trace file generation about invariant violation and also an
assertion when generating swiftdeps file.
rdar://122905379
allow a more standard way to pass experimental features
from build systems. Also moved other flags relevant to
diagnostics from Frontend options to Lang options.
Ref: rdar://124648653
Support `-vfsoverlay` swift option for explicit module build (including
caching build). Previously, if the interface file is discovered from a
location that is remapped by overlay, module cannot be built correctly.
Make sure the overlay options are passed down to all interface
compilaiton command.
For caching build, need to make sure the overlay itself is part of the CAS
file system so the downstream compilation can discover that.
rdar://123655183
Enabling `@_spiOnly` also enables stronger type-checking of SPI decls.
As this could be source breaking, it has always been opt-in. Turn it on
by default in Swift 6 mode where the stronger type-checking will also
become expected.
At the same time, disable the old alternative to `@_spiOnly` which was
designed to be compatible with old compilers. Any user of that feature
should move to `@_spiOnly` or `package import` instead.
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
* Add a new flag -experimental-package-cmo that requires -experimental-allow-non-resilient-access.
* Support serializing package decls for CMO in package if enabled.
* Only applies to default mode CMO.
* Unlike the existing CMO, package CMO can be built with -enable-library-evolution as package
modules are required to be built together in the same project.
* Create hasPublicOrPackageVisibility to opt in for package decls; needed for CMO, SILVerifier,
and other call sites that verify or determine codegen.
Resolves rdar://121976014
Do not encode cache invariant command-line flags in DWARF since those
flag should not affect code generation or diagnostics. This avoids
generating conflicting cache entry when caching is enabled, and will
make normal incremental builds more likely to hit fast skip codegen
path.
rdar://124222904
We don't currently support building resilient relative protocol witness tables.
One might want to build with relative witness tables but not need
resilient protocols. Allow for that scenario.
Add a test configuration to test library-evolution + fragile resilient
protocols + relative protocol witness tables.
Fix a stack-use-after-scope in the CachedDiagnostics when the
DiagnosticInfo entry that is getting deserialized has ChildDiagnostics.
There are some fields in the DiagnosticInfo are not owned by the
DiagnosticsInfo itself. While the callback during the deserialization
ensures those fields are still alive for the top level DiagnosticInfo
when it gets used, it is not true for any child diagnostics info inside.
rdar://123846525
Add an experimental option to tell dependency scanner to report clang
cc1 args should be used to construct clang importer in all constructed
swift-frontend tasks.
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.
When caching build is enabled, teach dependency scanner to report
command-lines with `-direct-clang-cc1-module-build` so the later
compilation can instantiate clang importer with cc1 args directly. This
avoids running clang driver code, which might involve file system
lookups, which are the file deps that are not captured and might result
in different compilation mode.
rdar://119275464
In rdar://123649082, a project failed to build because of the lazy import-as-member loading changes in #71320. That project was configured in a way that broke modularization and the correct solution is to fix it, but out of an abundance of caution, add a `-disable-named-lazy-import-as-member-loading` frontend flag in case a project needs to temporarily restore the old behavior.
As a bonus, this lets us write a test to verify that lazy import-as-member loading has positive performance impact.
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
