Importing C++ class templates in symbolic mode has proven to be problematic in interaction with other compiler features, and it isn't used widely. This change removes the feature.
rdar://150528798
If a module is blocklisted from the compiler using its textual interface, then under Implicitly-Built modules it will not get indexed, since indexing will not be able to spawn swiftinterface compilation. With explicitly-built modules, none of the dependency modules get built from interface during indexing, which means we directly index input binary modules.
For now, for functional parity with Implicit Module Builds, disable indexing of modules during Explicit Module Builds which would not get indexed during Implicit Module Builds.
`Hashing.h` is non-deterministic between runs. Update the index hashing
to use BLAKE3 for the record hash. xxhash is faster in benchmarks that
I've found, but there's no easy `HashBuilder` option for it today.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
When indexing an empty Swift file, we get a unit file that doesn’t have any record dependency declared on the source file. Because of this, we always assume that the empty file has an out of date index store entry and re-index it on project open. Write empty record files to fix this.
rdar://128711594
interface for index.
An explicit module build compile is unable to do so because it does not have
access to the interfaces. Doing this in the first place is a workaround for a
known bug, which will require to be solved at the root cause instead (e.g.
Deserialization Safety feature).
Resolves rdar://113165898
The order for writing records of the stdlib currently depends on
`StringMap` iteration (in a slightly roundabout manner). Sort these
alphabetically instead.
Calling getImportedModules requires to list the desired kind of imports.
With the new kind of imports this has become cumbersome. Let's simplify
it by offering common sets of imports. Advanced call sites can still
list the desired imports explicitly.
Rather than using `ModuleDecl::isSystemModule()` to determine whether a
module is not a user module, instead check whether the module was
defined adjacent to the compiler or if it's part of the SDK.
If no SDK path was given, then `isSystemModule` is still used as a
fallback.
Resolves rdar://89253201.
If a module was first read using the adjacent swiftmodule and then
reloaded using the swiftinterface, we would do an up to date check on
the adjacent module but write out the unit using the swiftinterface.
This would cause the same modules to be indexed repeatedly for the first
invocation using a new SDK. On the next run we would instead raad the
swiftmodule from the cache and thus the out of date check would match
up.
The impact of this varies depending on the size of the module graph in
the initial compilation and the number of jobs started at the same time.
Each SDK dependency is re-indexed *and* reloaded, which is a drain on
both CPU and memory. Thus, if many jobs are initially started and
they're all going down this path, it can cause the system to run out of
memory very quickly.
Resolves rdar://103119964.
Indexing a module from the swiftinterface puts the swiftinterface
version in the cache. Subsequent builds don't see the adjacent
swiftmodule file. This can break test clients that need the adjacent
swiftmodule information. To avoid this scenario, ensure that we only
index system modules in the SDK, not local versions.
rdar://102207620
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Swiftc port of https://github.com/apple/llvm-project/pull/4207.
This introduces a new flag, `-file-prefix-map` which can be used
instead of the existing `-debug-prefix-map` and `-coverage-prefix-map`
flags, and also remaps paths in index information currently.
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.
This makes it easier to specify OptionSet arguments.
Also modify appropriate uses of ModuleDecl::ImportFilter to take
advantage of the new constructor.
`SynthesizedFileUnit` is a container for synthesized declarations. Currently, it
only supports module-level declarations.
It is used by the SIL differentiation transform, which generates implicit struct
and enum declarations.
The fake module names we create when indexing a Swift module divided into
'groups' (e.g. the stdlib) don't have to be valid Swift module names, but we
were manipulating them to be so. E.g. the stdlib "Lazy Views" group, became
"Lazy_Views". This name is displayed in some editors verbatim, and is also
used as input to some sourcekitd APIs (e.g. editor.open.interface) that only
work if the original group name is passed, rather than the processed one.
This patch stops mapping invalid module name characters like ' ' and '-' to '_'
so the original group name remains.
Resolves rdar://problem/57270811
Several tests related to indexing system modules were taking a considerable
amount of time (100+ seconds in the worst case) indexing the standard library.
This adds a frontend option to skip it and updates those tests to pass it.
