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.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
`OptTable` was a source of consistent churn due to new arguments to the
`OPTION` macro. LLVM 3f092f37b7362447cbb13f5502dae4bdd5762afd extracted
the handling of the common option parts (eg. an ID and an info) out into
separate macros to reduce this - use those here (since unsurprisingly,
more arguments were added).
There is no need to serialize module deps when caching is on because the
entire build command has already capture the entire dependency tree.
There is no need to encode the has for all dependencies and try to
validate them.
rdar://122914546
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
ClangImporter’s SwiftLookupTables map Swift names to their corresponding Clang declarations. These tables are built into a module’s clang .pcm file and missing or inaccurate entries can cause name lookup to fail to find an imported declaration.
Swift has always included a helper function that would dump these tables, and swift-ide-test has a command-line switch that would invoke it, but these tools are clumsy to use in many debugging scenarios. Add a frontend flag that dumps the tables at the end of the frontend job, making it a lot easier to get at this information in the context of a specific compilation.
It's not thread safe and can cause false alarms in case multiple modules exist in different threads. E.g. when building swiftmodules from interfaces.
The leaking check is not important anymore because the builder APIs enforce that instructions are not leaking.
I.e. it's not possible to create an instruction without inserting it into a basic block. Also, it's not possible to remove an instruction from a block without deleting it.
rdar://122169263
