Previously, const-values output is not supported correctly as it is not
captured correctly as a dependency. The load of the input JSON file is
loaded via file system directly, that can cause issues like:
* False cache hit when the file is changed
* Cannot be prefix mapped to allow distributed caching
Try to support the input file by:
* Correctly capture the input
* Create a new driver flag `-const-gather-protocols-list` that can do
path remapping correctly in swift-driver
rdar://169109358
We've had several bugs lately where SILGen produces a diagnostic,
but the resulting invalid SIL causes crashes further down in the
mandatory pipeline. To prevent this from happening, just stop after
SILGen if diagnostics were emitted, even if lazy type checking is
disabled, because the same rationale applies in either case.
The option can be used to save the SIL after optimizations to a file.
In contrast to `-emit-sil`, the compiler doesn't stop an continues to e.g. create the regular output object file
In multi-threaded WMO builds, the frontend didn't properly handle per-file
supplementary outputs specified via output file maps or command-line
arguments.
This enables swift-driver to use -supplementary-output-file-map for
per-file outputs in multi-threaded WMO, instead of generating multiple
individual flags that the frontend rejects.
Make sure we emitted an error if we encountered an invalid conformance
error. This is important since `ASTContext::hadError` accounts for
such delayed errors, so we need to make sure we don't ever exit with
a non-zero exit code without emitting any error.
This reverts commit 4f059033bb. The change
is actually not NFC since previously, there is a cache in the
CompilerInvocation that prevents the same CAS from the same CASOptions
from being initialized multiple times, which was relied upon when
running inside sub invocation. When switching to a non-caching simple
CASOption types, it causes every single sub instance will create its own
CAS, and it can consume too many file descriptors and causing errors
during dependency scanning.
rdar://164903080
MCCAS wasn't setup correctly when using parallel WMO. Make sure the
CAS ObjectStore and ResultCallbacks are passed to LLVM backend when
using parallel WMO.
rdar://164409895
This commit adds -sil-output-path and -ir-output-path frontend options that
allow generating SIL and LLVM IR files as supplementary outputs during normal
compilation.
These options can be useful for debugging and analysis tools
workflows that need access to intermediate compilation artifacts
without requiring separate compiler invocations.
Expected behaviour:
Primary File mode:
- SIL: Generates one .sil file per source file
- IR: Generates one .ll file per source file
Single-threaded WMO mode:
- SIL: Generates one .sil file for the entire module
- IR: Generates one .ll file for the entire module
Multi-threaded WMO mode:
- SIL: Generates one .sil file for the entire module
- IR: Generates separate .ll files per source file
File Maps with WMO:
- Both SIL and IR outputs using first entry's naming, which is
consistent with the behaviour of other supplementary outputs.
rdar://160297898
Introduce the ability to form a `StaticBuildConfiguration` from
language options. Add a frontend option `-print-static-build-config`
to then print that static build configuration as JSON in a manner that
can be decoded into a `StaticBuildConfiguration`.
Most of the change here is in sinking the bridged ASTContext queries
of language options into a new BridgedLangOptions. The printing of the
static build configuration only has a LangOptions (not an ASTContext),
so this refactoring is required for printing.
If these programs crash, we want them to print the Swift bug report
message, not the default LLVM one, which leads to
https://github.com/llvm/llvm-project/issues.
While here, hoist the setting of the bug report message to the
START_PROGRAM macro so that we don't forget to set it in the future.
Parser errors with large Swift module map files can be hard to diagnose.
Refactor the parser to return an llvm::Error so clearer diagnostics can
be passed to the user.
SwiftVerifyEmittedModuleInterface job is configured to be built within
the SubInvocation and it needs to inherit the caching replay prefix map
in order to load macro plugin library correctly.
rdar://158692095
When building a module interface for the -typecheck-module-from-interface or
-compile-module-from-interface actions, inherit and honor compiler debugging
options and emit debugging output at the end of the interface build.
Add a new option `-gen-reproducer` that when swift caching is used,
create a standalone reproducer that can be used to reproduce the
`swift-frontend` invocation.
The "featues" part was never actually implemented and Swift Driver
is replying on information about arguments, so instead of removing
this mode, let's scope it down to "arguments" to be deprecated in
the future.
This is a replacement for `-emit-supported-features` that prints
all of the upcoming/experimental features supported by the compiler
with some additional meta information in JSON format to stdout.
Use a null diagnostic consumer in the deterministic verify instance. The
constraint system will skip work if there are no consumer in the
diagnostic engine. Use a null consumer to make sure the same amount of
work is done for two runs.
This adds the compiler configuration to the output similar to clang.
This will allow us to identify the compiler build type, e.g.
```
Swift version 6.2-dev (LLVM 47665e034aa6f27, Swift 2b3e5dac59b8632)
Target: x86_64-unknown-windows-msvc
Build config: +unoptimized,+assertions,+expensive-checks,+asan,+hwasan,+msan,+ubsan
```
* Include `DeclContext` of the node where possible
* Add 'default-with-decl-contexts' dump style that dumps the dect context
hierarchy in addition to the AST
* Support `-dump-parse` with `-dump-ast-format json`
This flag is unsafe since the compiler does not verify that the resulting
public interface will compile with the module import removed. The modern
alternative to this flag is `@_spiOnly import`. Since the flag is no longer
used by any projects it should be removed.
Resolves rdar://134351088.
Batch dependency scanning was added as a mechanism to support multiple compilation contexts within a single module dependency graph.
The Swift compiler and the Explicitly-built modules model has long since abandoned this approach and this code has long been stale. It is time to remove it and its associated C API.
This only takes the existing AST information and writes it as JSON
instead of S-expressions. Since many of these fields are stringified,
they're not ideal for the kind of analysis clients of the JSON format
would want to do. A future commit will update these values to use a
more structured representation.
There were two cache replay code exists, one for cache replay from
swift-frontend, the other for replay using C API from libSwiftScan. It
is easy to forget to update one copy when new specialized cache replay
logic is added for some output kinds. Now unify the replay logics to a
single location to avoid confusion. This is a rewrite of the existing
logic and NFCI.
Anthony Latsis
Steven Wu
Slava Pestov
Erik Eckstein
Hamish Knight
Ryan Mansfield
Alex Hoppen
Doug Gregor
Richard Howell
Allan Shortlidge
Arnold Schwaighofer
Pavel Yaskevich
Saleem Abdulrasool
Tony Allevato
Tony Allevato
Saleem Abdulrasool
Rintaro Ishizaki
Meghana Gupta
Artem Chikin
Hiroshi Yamauchi
Xi Ge