Make swift caching remarks more friendly to use by:
* Allow environmental variable `SWIFT_ENABLE_COMPILE_CACHE_REMARK` to
control if the remarks are emitted or not. This avoids updating and
reconfiguring build flags just to see the caching remarks.
* Add a new cache hit remark on top of the existing cache replay output
remarks. Cache output replay remark is one per output, while cache hit
remark is one per invocation. This allows better cache hit/miss rate
calculation just based on the number of remarks emitted.
rdar://178563432
Add -ipi-clang-module flag to enforce IPI library level for Clang modules.
Compiler stores names of those modules and checks them during typechecking.
rdar://177196788
All blocklists are currently provided by build system as compiler flags explicitly. We shouldn't
need to infer those blocklist paths from the resource dir. Additionally, one recent change from Pavel (https://github.com/swiftlang/swift/pull/88631)
shows that the inference logics never worked in the first place. Let's take this opportunity to drop it.
rdar://176993716
The default code generation model for Embedded Swift is "inlinable".
DeferredCodeGen made the default code generation model
"implementation", and there was no spelling for "interface".
Introduce the experimental feature CodeGenerationModel=<model>, which
can be any of those three options. The default remains "inlinable", but
one can now specify "implementation" (which keeps most everything in
SIL) or "interface" (which only keeps the generic things in SIL). The
"interface" mode is more like non-embedded Swift for non-generic
declarations, emitting them into the IR (only) but not SIL. Generic
declarations would remain in SIL.
Implements rdar://172433062.
llvm::cl::opt flags are compiled out in non-asserts builds, making these
debug flags unavailable in an important category of use cases — debugging
a release compiler in lldb. By promoting them to Swift frontend flags stored
in DiagnosticOptions/SILOptions, they are available in all build
configurations.
The three existing flags are migrated:
-diagnostics-assert-on-error
-diagnostics-assert-on-warning
-sil-region-isolation-assert-on-unknown-pattern
(backing field renamed to AbortOnUnknownRegionIsolationPatternError)
A new flag is added:
-diagnostics-assert-on-group <group>
Traps when any diagnostic belonging to the named group is emitted,
allowing targeted breakpoints on a single diagnostic group rather than
all errors or all warnings.
The assert-on-{error,warning,group} flags are intentionally kept separate
from the normal diagnostic suppression/escalation machinery so that they
remain useful while other diagnostics are also being emitted.
Tests are added for all four flags.
Normally macro expansions are typechecked through the normal traversal
of the AST. This does not happen with macro expansions in clang modules
however, since the clang module is not traversed by the typechecker.
This is not too problematic, since all the code in clang modules is
generated by the toolchain, so incorrect code would only occur when
there's a bug in the toolchain. Catching these bugs would be a lot
easier if we actually ran the typechecker during testing. We don't want
to do this normally, as it breaks the laziness of the typechecking, so
this adds -eager-macro-checking to specifically enable this behavior.
It's intended for testing purposes only.
`llvm::sys::path::extension` produces an extension together with
the leading `.` which the original code didn't respect. We also
don't care about any other components as long as the last one is
`.yaml` or `.yml`.
Make `-const-gather-protocols-list` behaves just like
`-const-gather-protocols-file` as a frontend flag. This is cause
swift-driver needs to query the frontend flag to see if the compiler
supports the feature. It was a driver flag only, which causes the
swift-driver failed to prefix mapping the file, results in build
failures.
rdar://175194244
With this option enabled the DiagnosticVerifier enforces a strict child
note hierarchy: if a note has a parent diagnostic (which it should), it
can only be matched by an expected-note matcher in the {{children:}}
block of the matcher of its parent diagnostic. This makes it clear when
reviewing which note belongs to which diagnostic, and lets
update-verify-tests keep that structure (support in update-verify-tests
not yet added). If the note is far away from the parent it can be
matched with a line marker (#foo on the line of the emitted note).
Without this option enabled (default behavior) {{children:}} blocks are
an error.
Additionally, change the verification error sort order to use buffer
ID as the primary key (address within buffer as secondary), so that
error output is stable across source files in multi-file compilations.
Support for existentials in Embedded Swift has been available for a
little while now and appears to be solid. Remove the ability to disable
them (via `-disable-experimental-feature EmbeddedExistentials`), both
because it simplifies the code and because it's an ABI break to
disable the feature.
We previously forwarded `-sysroot` as `-isysroot` which reached cc1, but
left the driver's view of sysroot empty which is used to derive the
system include paths. Thread `--sysroot=` into the clang importer,
ensuring that we do not do so with `-direct-clang-cc1-module-build` as
that directly goes to CC1 rather than the driver.
**Explanation**: Existing `wasip1` triples for Embedded Swift already support concurrency, so this import should be implicit and no longer require package authors to make it explicit for Embedded Swift for WASI compatibility.
**Scope**: limited to Embedded Swift for Wasm;
**Risk**: low due to limited scope;
**Testing**: added a new lit test that verifies the change.
**Issue**: rdar://174021193
With the new option, when doing caching we write the hash that we already
computed for the main output file to an extended attribute (xattr) on the file.
This is equivalent to clang's -fwrite-output-hash-xattr option.
The format of the xattr is
name: com.apple.clang.cas_output_hash
data:
* Null-terminated hash schema name, e.g. llvm.builtin.v2[BLAKE3].
* Hash length (4 bytes, little-endian).
* Hash bytes
rdar://171185394
This no longer causes a regression in number of CAS instances.
Prefer llvm::cas::CASConfiguration where it used to clang::CASOption.
(cherry picked from commit 4f059033bb)
Fix the debug info emitted for bridging header PCH when compilation
caching is used. This includes:
* Bridging header should have the correct dwo_name that uses CASID
* The search_path for PCH should be the cache key that can load the PCH
just like other modules.
`-enable-experimental-feature SourceWarningControl` guards the actual *use* of `@warn` attribute, but it did not guard this logic which queries it, which is meant to be general in the absense of the attribute as well.
We are seeing some unintended compile time performance implications from this logic, so for now guard it behind the same experimental feature flag.
Related to rdar://171506799
This mirrors Clang's `-fsanitize=fuzzer-no-link`, which applies the
appropriate instrumentations but does not attempt to link to the
runtime library. More importantly, this suppresses the check in the
driver that fails the build if the library cannot be found. Since
libfuzzer is not distributed with Xcode, this allows users to build
it themselves or take it from a swift.org toolchain and use it
without having to physically copy/link it into their toolchain's
runtime directory.
Add flag `-debug-module-cache-key` and flag `-debug-module-self-key` to
support embedded swift module output in the debug info via CASID.
rdar://169110002
If a .swiftinterface file does not include an explicit `-language-mode` option
(or its predecessor `-swift-version`) and needs to be built as a dependency of a
client compilation, then the invocation to build the module from interface
would end up inheriting the language mode that the client code is built with.
This can result in spurious type checking diagnostics or even mis-compilation.
To ensure that a module interface is always built using the language mode that
its source code was originally built with, require an explicit `-language-mode`
option when emitting swiftinterface files.
In #84307 this diagnostic was downgraded to a warning. The failures it caused
in PR testing should now be resolved.
This is a re-attempt of https://github.com/swiftlang/swift/pull/84327.
Resolves rdar://145168219.
As specified in SE-0441, -language-mode should appear in help output
while -swift-version should be the hidden alias.
Related to swiftlang/swift-driver#1894
During explicit module build, teach dependency scanner to emit the
module trace file instead of each following compile job command. This
reduces the duplicated info, and allows supporting fully cached build
that only loads module from CAS thus cannot produce the path to the
original module file on disk.
rdar://170007480
Steven Wu
Sam Pyankov
Henrik G. Olsson
John Hui
Xi Ge
Doug Gregor
Michael Gottesman
Artem Chikin
Pavel Yaskevich
Henrik G. Olsson
Keith Smiley
Kavon Farvardin
Pavel Yaskevich
CognitiveDisson
Saleem Abdulrasool
Max Desiatov
Ben Langmuir
Tony Allevato
Tony Allevato
Adrian Prantl
Slava Pestov
Allan Shortlidge
finagolfin
Ryan Mansfield
Becca Royal-Gordon