Fix a longstanding bug in the driver where the incremental build would
fail to execute dependent jobs and allow errors in primaries in later
waves to become buried. A simplified version of a situation that exposes
this bug has been committed into the tests.
Imagine two files:
```
// one.swift
struct A {}
// two.swift
func use() {
let _ = A()
}
```
After a clean build, we modify one.swift as follows:
```
// one.swift
struct B< {}
```
The syntax error in this file caused the baseline driver to fail the
build immediately and thus we would not schedule two.swift for
execution. This is incorrect! Consider correcting the syntax error in
one.swift:
```
// one.swift
struct B {}
```
two.swift _still_ won't be rebuilt because
1) It was never modified during any step of this process
2) The swiftdeps of two.swift have not been updated to flush out the
dependency on A.
rdar://72800626
This commit refactors ScanDependencies.cpp to split the functionality into two functional groups:
- Scan execution code that performs the mechanics of the scan and produces an in-memory result
- Dependency scanner entry-points used when the scanning action is invoked as a `swift-frontend` execution mode
This commit also adds the aforementioned in-memory dependency scanning result in `FullDependencies.h`, modeled after the InterModuleDependencyGraph representation in swift-driver
It is now the responsibility of the scanDependencies code to instantiate (and share) the cache.
e.g. FrontendTool instantiates a new cache per `-scan-dependencies` invocation, and the DependencyScanningTool keeps one shared cache across its lifetime.
Introducing new entry-points that can be used from both Driver and Frontend clients, using an intermediary new type: `DetailedMessagePayload`, when needed.
Starting at a crude -1000, each invocation primary input will get its own unique quasi-Pid.
Invocations with only one primary (non-batch) will get a real OS Pid.
The selection of the constant starting point matches what the driver does when outputting its parseable output.
Follow programming guidelines for these getters more closely and have them return a non-owning view of the underlying data instead of relying on callers to take const references to the copy that is returned here.
T *const does not prevent logically non-const accesses to the underlying data, it merely indicates that the pointer value itself is const. This modifier can be cast off by a copy, so it's not generally what you want here. Switch to const T * instead.
Adds a new frontend option
"-experimental-allow-module-with-compiler-errors". If any compilation
errors occur while generating the .swiftmodule, this mode will skip SIL
entirely and only serialize the (likey invalid) AST.
This existence of this option during generation is serialized into the
resulting .swiftmodule. Errors found in deserialization are only allowed
if it is set.
Primarily intended for IDE requests (eg. indexing and code completion)
to ensure robust cross-module results, despite possible errors.
Resolves rdar://69815975
The new message is:
"Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace."
1. In crash logs we used to print a message which points to the llvm bug tracking page. Now it points to the swift.org bug tracking guidelines.
2. Use the same message in all compiler diagnostics which ask the user to file a bug report.
rdar://problem/70488534
To help consolidate our various types describing imports, this commit moves the following types and methods to Import.h:
* ImplicitImports
* ImplicitStdlibKind
* ImplicitImportInfo
* ModuleDecl::ImportedModule
* ModuleDecl::OrderImportedModules (as ImportedModule::Order)
* ModuleDecl::removeDuplicateImports() (as ImportedModule::removeDuplicates())
* SourceFile::ImportFlags
* SourceFile::ImportOptions
* SourceFile::ImportedModuleDesc
This commit is large and intentionally kept mechanical—nothing interesting to see here.
Also perform the plumbing necessary to convince the rest of the compiler that they're just ordinary external dependencies. In particular, we will still emit these depenencies into .d files, and code completion will still index them.
Invert the responsibility of the entrypoint so that FrontendTool is directing the actual serialization work. The entrypoint now solely exists to construct a dependency graph.
While I'm here, prepare the way for serializing dependency graphs for modules by optimistically modeling a ModuleOrSourceFile input.
For now, force the clang-based actions to skip the end of the pipeline. This restores the previous behavior of the frontend, but may not be desirable in the long run. For example, one may want to dump clang stats after running an -emit-pch job, but that is impossible without forcing the end of the pipeline to be more tolerant of ObjCHeader/modulemap-only inputs.
rdar://68587228
Try to impose a simple structure that splits performing actions from the
pre and post-pipeline conditions. Wherever actions would take more than
a simple return, split them into functions. Refine functions that
perform effects to return status codes when they fail. Finally,
delineate functions that need semantic analysis from those that do not.
Overall this should be NFC.
