Rather than adding a ModuleFile to a parent module
and then removing it afterwards if it fails to
load, let's wait until we've loaded the file before
deciding to add it to the parent module. This then
allows us to get rid of `ModuleDecl::removeFile`.
In addition, push down the calls to `addFile` into
the callers of `loadAST` in preparation for
`addFile` being replaced with a one-time-only call
to a `setFiles` method.
Using a SetVector fixes an issue where many source files imported the
same SPI group from the same module, the emitted private textual
interfaces superfluously repeated the `@_spi` attribute on the import.
rdar://problem/63681845
Permit the directory style `.swiftmodule` on non-Apple targets. This
allows all platforms to use the directory layout enabling
multi-architecture SDKs. This not only unifies the layout of the SDK
across the various targets, it also enables Windows to have a single
unified SDK.
The complexity here is due to the compatibility for older layouts. This
change does not break compatibility on Linux/Android/Windows for the old
style layout.
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.
We weren't handling this case, so their generated interfaces / doc info
wouldn't include symbols from the cross-import overlays, and we wouldn't
map the underscored cross-import overlay name back to the declaring
framework's name in cusor-info, completion results or when indexing.
Resolves rdar://problem/62138551
Before this change, we would emit the warning only for swiftmodules; however,
it may be the case that only a swiftinterface (of a different arch) is present
but no swiftmodule is present.
Fixes rdar://problem/50905075.
Query the SourceLookupCache for the operator decls,
and use ModuleDecl::getOperatorDecls for both
frontend stats and to clean up some code
completion logic.
In addition, this commit switches getPrecedenceGroups
over to querying SourceLookupCache.
Serialize derivative function configurations per module.
`@differentiable` and `@derivative` attributes register derivatives for
`AbstractFunctionDecl`s for a particular "derivative function configuration":
parameter indices and dervative generic signature.
To find `@derivative` functions registered in other Swift modules, derivative
function configurations must be serialized per module. When configurations for
a `AbstractFunctionDecl` are requested, all configurations from imported
modules are deserialized. This module serialization technique has precedent: it
is used for protocol conformances (e.g. extension declarations for a nominal
type) and Obj-C members for a class type.
Add `AbstractFunctionDecl::getDerivativeFunctionConfigurations` entry point
for accessing derivative function configurations.
In the differentiation transform: use
`AbstractFunctionDecl::getDerivativeFunctionConfigurations` to implement
`findMinimalDerivativeConfiguration` for canonical derivative function
configuration lookup, replacing `getMinimalASTDifferentiableAttr`.
Resolves TF-1100.
Introduce DirectOperatorLookupRequest &
DirectPrecedenceGroupLookupRequest that lookup
operator and precedence groups within a given
file or module without looking through imports.
These will eventually be used as the basis for the
new operator lookup implementation, but for now
just use them when querying lookup results from
serialized module files.
The diagnostic function crashed as it did not take into account the
DebuggerSupport options as the site reporting the missing dependency did.
In this context, missing implementation-only imported dependencies are
ignored only if DebuggerSupport is set.
When a module extends a type from another module, serialize those symbols into
separated files dedicated to those extended modules. This makes it easier to
ingest and categorize those symbols under the extended module if desired.
rdar://58941718
