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.
To allow tooling to analyze use of language mode and experimental/upcoming
features, add that information to the `.SWIFT_TRACE` file.
Resolves rdar://152673681.
Most `SemaAnnotator`s don’t actually care about the char source range. Instead, they only care about the start location of the reference, which is also included in `SourceRange`. Computing a `CharSourceRange` from a `SourceRange` is kind of expensive because it needs to start a new lexer.
To avoid this overhead, pass `SourceRange` to `SemaAnnotator::passReference` and related functions and let the clients compute the `CharSourceRange` when needed.
This reduces the overhead of index-while-building by about 10%.
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.
Extend the module trace format with a field indicating whether a given
module, or any module it depends on, was compiled with strict memory
safety enabled. This separate output from the compiler can be used as
part of an audit to determine what parts of Swift programs are built
with strict memory safety checking enabled.
CAS needs to determine if an output is needed very early (when computing supplementary outputs) in the pipeline so we can do caching and replays.
Resolves: rdar://141850408
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.
Emitting fine-grained module tracing files during full compilation should be sufficient for the use case in design. Other
swift-frontend invocations, such as emitting modules, doesn't need fully type-checked AST to perform the action, therefore
requesting/walking the fully typechecked AST to emit those tracing files may introduce performance overhead.
When lazy type checking is enabled, the generated AST to walk on may contain function bodies that
are not fully type-checked. Walking on these function bodies could expose latent bugs.
Resolves rdar://140818215
CAS support in compiler relies on supplementary paths to decide the mapping between input and output files. Therefore, we
have to compute the paths of the module ObjC trace files in this canonical place to have CAS support for
this newly added ObjC message trace files.
To simplify post-processing of these collected ObjC message traces, this PR teaches the compiler to atomically append the content of
ObjC message trace to a file location provided by the build environment, instead of emitting multiple files.
