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.
Fully support make-style `.d` dependencies file output by making
following improvements:
* All correct dependency file render when cache hit for a different
output file location. The dependency file should list the correct
output path, not the stale output path for the initial compilation
* When enable a path prefix mapper to canonicalize the path, the
dependency file should render the input file correctly as the input
file path on disk.
rdar://132250067
This removes the implementation of the `swift-indent` tool, its
associated documentation, and utilities. This tool was never completed
and has much better alternatives with `swift-format` which is more
flexible and actually maintained.
The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.
Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.
Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
For batch compile jobs, it's helpful to see which files are considered primary
and that was the original reason why filelist contents were printed in compiler
crash stack dumps. However, for whole module compile jobs, the contents of the
filelist is uninteresting (it's just all the files in the module) and can be
hundreds or thousands of lines long so it often causes important information to
be trimmed from stack dumps received in reproducers.
In lazy typechecking mode, errors in the program may only be discovered during
SILGen, which can leave the SIL in a bad state for subsequent stages of
compilation. If errors were detected, skip SIL verification and optimization to
prevent knock-on failures.
Partially reverts https://github.com/swiftlang/swift/pull/75428, which included
a more targeted fix for one of the possible knock-on effects of bad SIL coming
out of SILGen.
Resolves rdar://132107752.
Foundation needs to be loaded early in the process for Swift's runtime
to properly initialize bridging support; otherwise it may cause issues
like unrecognized selectors. When scripting, load Foundation early in
performFrontend before any swift code runs.
rdar://129528115
Conflicts:
- `test/Interop/Cxx/class/method/methods-this-and-indirect-return-irgen-itanium.swift`
previously fixed on rebranch, now fixed on main (slightly differently).
This patch adds support for MCCAS when a cache hit is encountered when
trying to replay a compilation, and uses the MCCAS serialization code
to materialize the object file that is the main output of the
compilation.
Now that API descriptions are emitted during module build jobs when
`-emit-api-descriptor-path` is specified and the build system has been updated
to pass that flag when the output is needed, the `swift-api-extract` frontend
alias is no longer used. Delete it and the tests that were specific to invoking
`swift-api-extract`.
Resolves rdar://116537394.
