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
ClangImporter’s SwiftLookupTables map Swift names to their corresponding Clang declarations. These tables are built into a module’s clang .pcm file and missing or inaccurate entries can cause name lookup to fail to find an imported declaration.
Swift has always included a helper function that would dump these tables, and swift-ide-test has a command-line switch that would invoke it, but these tools are clumsy to use in many debugging scenarios. Add a frontend flag that dumps the tables at the end of the frontend job, making it a lot easier to get at this information in the context of a specific compilation.
Serialize a `--target=` flag (a driver option) instead of `-triple` (a frontend
option). The `XCC` values are passed as driver flags, where `-triple` is not defined.
The target is passed as a joined flag and value, which is more convenient for lldb to
consume.
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
The Swift compiler can load either the binary swiftmodule file or the
textual swiftinterface file when importing a module. It currently picks
the swiftmodule over the swiftinterface, unless there’s an exception. We
should flip the default for distributed modules, prefer the
swiftinterface over the swiftmodule unless there’s an exception.
rdar://122955640
