Various processes, such as launchd, are unsafe to inspect directly. Inspecting them pauses them and the system does not like it when they're paused. Forking a corpse avoids this, as the original process continues running while we inspect the forked corpse.
VMUProcInfo provides a shouldAnalyzeWithCorpse call which tells us whether we're inspecting one of those processes. When we are, then we force the forkCorpse option even when it's not specified.
Add shims to Symbolication+Extensions.swift to allow calls to VMUProcInfo and use it to force forkCorpse when appropriate.
rdar://124720793
Resolving cursor info is async and can occur after the request has been
deleted, make sure to take a copy of the `USR` (which is part of that
request).
Resolves rdar://137320169.
Providing these is a bit of a layering violation,
the parser shouldn't care about these options (there
does seem to be one current use of `TypeCheckerOpts`
in the parser for designated operator types, but
that's a legacy feature that was never officially
supported).
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.
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.
This commit adds new compiler options -no-warning-as-error/-warning-as-error which allows users to specify behavior for exact warnings and warning groups.
