This will enable users to try out the '-enable-ossa-modules' flag if their
compiler supports it and get OSSA code on all inlinable code that they use. The
idea is that this is a nice way to stage this in and get more testing.
The specific implementation is that the module interface loader:
1. Knows if enable ossa modules is enabled not to search for any compiled
modules. We always rebuild from the interface file on the system.
2. Knows that if enable ossa modules is enabled to mixin a bit into the module
interface loader cache hash to ensure that we consider the specialized ossa
compiled modules to be different than the modules in that cache from the system.
This ensures that when said flag is enabled, the user transparently gets all
their code in OSSA form from transparent libraries.
In the legacy driver, these flags will merely be propagated to the
frontends to indicate that they should disable serialization of
incremental information in swift module files.
In the new driver, these flags control whether the Swift driver performs
an incremental build that is aware of metadata embedded in the module.
Kudos to David for coming up with our new marketing name: Incremental
Imports.
rdar://74363450
These new options mirror -o and -output-filelist and are used instead
of those options to supply the output file path(s) to record in the
index store. This is intended to allow sharing index data across
builds in separate directories that are otherwise equivalent as far
as the index data is concered (e.g. an ASAN build and a non-ASAN build)
by supplying the same -index-unit-output-path for both.
Resolves rdar://problem/74816412
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
