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.
This is something that I have wanted to add for a while and have never had the
need to. I need it now to fix a bug in the bots where I am forced to use IRGen
output to test ThunkLowering which causes platform level differences to show up
in the FileCheck output. With this, I can just emit the actual lowered SIL
output and just test it at that level. There are other cases like this where we
are unable to test lowered SIL so we use IRGen creating this brittleness.
Hopefully this stops this problem from showing up in the future.
rdar://138845396
This mode is similar to `swift-symbolgraph-extract`; it takes a subset of compiler
flags to configure the invocation for module loading, as well as a module name
whose contents should be extracted. It does not take any other input files. The
output is a single text file specified by `-o` (or `stdout` if not specified).
While the most common use case for this would be viewing the synthesized Swift
interface for a Clang module, since the implementation simply calls
`swift::ide::printModuleInterface` under the hood, it's usable for any module
that Swift can import. Thus, it could also be used to view a synthesized textual
representation of, say, a compiled `.swiftmodule`.
One could imagine that in the future, we might add more flags to
`swift-synthesize-interface` to modify various `PrintOptions` used when
generating the output, if we think those would be useful.
When the size of the array accessed here is zero, retrieving the
address of the zero-th element here is undefined. When the frontend
is linked against a libc++ that has the `unique_ptr` hardening in
[this commit](18df9d23ea)
enabled, it traps here.
Instead, simply call `.get()` to retrieve the address of the
array, which works even when it is a zero-byte allocation.
