Adjust the build rules to use the `LibXml2::LibXml2` target rather
than use the explicit include paths and link flags. This allows us to
track additional dependencies (implicit linked libraries) as well as
properly propagate the include paths and library search paths.
This addition will allow us to cross-compile swift-inspect to Windows
ARM64. Enabling the Windows ARM64 build permits the toolchain to become
more similar across the architectures.
Rather than exposing an `addFile` member on
ModuleDecl, have the `create` members take a
lambda that populates the files for the module.
Once module construction has finished, the files
are immutable.
We shouldn't be attempting to append SourceFiles
to the module after-the-fact for syntactic macro
expansion, refactor things such that the SourceFile
is created alongside the ModuleDecl.
Previously, they were being parsed as top-level code, which would cause
errors because there are no definitions. Introduce a new
GeneratedSourceInfo kind to mark the purpose of these buffers so the
parser can handle them appropriately.
Add flag `-load-resolved-plugin` to load macro plugin, which provides a
pre-resolved entry into PluginLoader so the plugins can be loaded based
on module name without searching the file system. The option is mainly
intended to be used by explicitly module build and the flag is supplied
by dependency scanner.
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.
