And also rename the underlying request and
descriptor.
This rename is motivated by the fact that the
operation may instead perform parsing of SIL files
and/or deserialization of SIB files.
This default formatting style remains the same "LLVM style". "Swift style"
is what was previously enabled via -enable-experimental-diagnostic-formatting
There's no longer a technical reason to do this, but it helps
with crash analytics because AST crashes are less likely to
end up happening during index emission.
Rather than eagerly parsing an input .sil file
in `performSemaUpTo`, trigger it from
`performSILGeneration`. This will allow us to
remove the SILModule stored on the
CompilerInstance and will eventually allow the
various SIL tools to just call into
`performSILGeneration` without needing to call
`performSema`.
As part of eliminating cascading dependencies, we need to make sure to
capture any dependencies discovered during SILGen and IRGen.
This is a little bit tricky because we exit early in various places in
the pipeline, so we want to do it after performCompileStepsPostSema()
returns, but we can't do it too late, because the ASTContext might
already have been deallocated.
So emit the dependencies manually before freeing the ASTContext if we
decide to do that, or just do it before returning from performCompile()
using a SWIFT_DEFER otherwise.
This should have no observable effect until we start recording dependencies
for lookups done on behalf of declarations in secondary files.
Add a mode bit to the dependency collector that respects the frontend flag in the previous commit.
Notably, we now write over the dependency files at the end of the compiler pipeline when this flag is on so that dependency from SILGen and IRGen are properly written to disk.
MSVC does not realize that the switch is exhaustive and requires that
the path is explicitly marked as unreachable. This silences the C4715
warning ("not all control paths return a value").
Implement a new "fast" dependency scanning option,
`-scan-dependencies`, in the Swift frontend that determines all
of the source file and module dependencies for a given set of
Swift sources. It covers four forms of modules:
1) Swift (serialized) module files, by reading the module header
2) Swift interface files, by parsing the source code to find imports
3) Swift source modules, by parsing the source code to find imports
4) Clang modules, using Clang's fast dependency scanning tool
A single `-scan-dependencies` operation maps out the full
dependency graph for the given Swift source files, including all
of the Swift and Clang modules that may need to be built, such
that all of the work can be scheduled up front by the Swift
driver or any other build system that understands this
option. The dependency graph is emitted as JSON, which can be
consumed by these other tools.
Inline the conditions for the astGuaranteedToCorrespondToSIL parameter and clean up the logic here to be more const-friendly. Also try to centralize and document the reasons we skip TBD validation.
The Remarks Streamer's installation seemed a bit overly complex, so simplify it in a few places:
* Refactor sil-opt to install the remarks options into the SILOptions for the SILModule
This reduces the parameter bloat in createSILRemarkStreamer. All of this data is freely derivable from the SILModule alone.
* Refactor createSILRemarkStreamer into SILRemarkStreamer::create
With the new reduction in parameters, we can hide the internal constructor and introduce a smart constructor that vends a unique pointer to clients.
* setSILRemarkStreamer -> installSILRemarkStreamer
Since the information to create a streamer is now entirely derivable from a module, remove a layer of abstraction and have the module directly construct a streamer for itself.
* Give SILRemarkStreamer its own LLVMContext
The remarks streamer just needs scratch space. It's not actually "installed" in a given context. There no reason to use Swift's Global Context here.
* Give the SILRemarkStreamer ownership of the underlying file stream
The SILModule didn't actually use this member, and it seems like somebody needs to own it, so just give it to the remarks streamer directly.
This simplifies fixing the master-next build. Upstream LLVM already
has a copy of this function, so on master-next we only need to delete
the Swift copy, reducing the potential for merge conflicts.
swift::GeneratedModule encapsulates an llvm::Module, llvm::LLVMContext
pair that must live and die together. It has convenient accessors for
projecting the module and context components. The meat of this type is
the two conversion functions, which transfer ownership of either the
module component to the caller or the module and context to ORCJIT.
This is because ORC enforces an ownership contract that is distinct from
LLVM's rather wild ownership story for modules and their associated
contexts. See http://llvm.org/docs/ORCv2.html#how-to-use-threadsafemodule-and-threadsafecontext
