If a function uses a type imported as implementationOnly (or similar), it cannot be serialized.
I added a new API in ModuleDecl (canBeUsedForCrossModuleOptimization), which performs this check.
rdar://72864719
When importing Clang types.
This is not an option with Explicit Module Builds. If the module being built does not (directly or transitively) depend on `Foundation`, then attempting to load it will produce an error because Implicit module loading is no longer allowed..
This change addresses a small number of cases where ClangImporter relies on being able to load `Foundation` on-demand:
- When importing a single Decl from a clang module, we check whether it has certain conformances by checking all extensions of the NominalTypeDecl of the Decl in question, to see if any of the extensions contain the conformance we are looking for, but we only check extensions whose parent module is either the original module of the NominalTypeDecl or the overlay module of the NominalTypeDecl or Foundation. It seems that we do not need to actually import `Foundation` here, just checking the module Identifier should be sufficient.
- In `maybeImportNSErrorOutParameter`, change the behavior to have an exit condition based on whether `Foundation` can be imported, before attempting to load it.
- When checking whether or not we are allowed to bridge an Objective-C type, it also looks sufficient the query whether or not `Foundation` *can* be imported, without loading it.
```
@_specialize(exported: true, spi: SPIGroupName, where T == Int)
public func myFunc() { }
```
The specialized entry point is only visible for modules that import
using `_spi(SPIGroupName) import ModuleDefiningMyFunc `.
rdar://64993425
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.
The lack of clarity manifested as unexpected behavior when using
getImportedModules to create the module import graph. The new behavior
makes SPI-ness and Shadowing-ness behave similarly in terms of
filtering. We also check if a filter is well-formed to avoid
accidental empty import lists.
The parameter here was derived from the CompilerInvocation-level parsing bits, which doesn't make any sense. This state is going away soon, so drop the parameter.
Extensions to implementation-only types are accepted at type-checking
only if they don't define any public members. However if they declared a
conformance to a public type they were also printed in the
swiftinterface, making it unparsable because of an unknown type.
Still accept such extensions but don't print them.
rdar://problem/67516588
Remove the `PrimarySourceFiles` vector from the
frontend and replace it with a request on
ModuleDecl that retrieves the primary files for
the main module.
This is in preparation for having
`CompilerInstance::getMainModule` automatically
populate the main module with files when queried.
Start asserting in `ModuleDecl::getFiles`
that the module is either non-empty or has
failed to load. This ensures that module
loading doesn't attempt to query the module's
files until the ModuleFile has been installed.
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
Re-implement operator and precedencegroup decl
lookup to use `namelookup::getAllImports` and
existing decl shadowing logic. This allows us to
find operator decls through `@_exported` imports,
prefer operator decls defined in the same module
over imported decls, and fixes a couple of other
subtle issues.
Because this new implementation is technically
source breaking, as we can find multiple results
where we used to only find one result, it's placed
behind the new Frontend flag
`-enable-new-operator-lookup` (with the aim of
enabling it by default when we get a new language
mode).
However the new logic will always be used if the
result is unambiguous. This means that e.g
`@_exported` operators will be instantly available
as long as there's only one candidate. If multiple
candidates are found, we fall back to the old
logic.
Resolves SR-12132.
Resolves rdar://59198796.
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
Add ModuleImplicitImportsRequest, which computes
the modules that should be implicitly imported by
each file of a given module. Use this request in
import resolution to add all the necessary
implicit imports.
The request computes the implicit imports by
consulting the ImplicitImportInfo, which ModuleDecl
can now be created with. This allows us to remove
uses of `SourceFile::addImports` in favor of
adding modules needed to be implicitly imported to
the ImplicitImportInfo.
`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.
Switch the direct operator lookup logic over to
querying the SourceLookupCache, then switch the
main operator lookup logic over to calling the
direct lookup logic rather than querying the
operator maps on the SourceFile.
This then allows us to remove the SourceFile
operator maps, in addition to the logic from
NameBinding that populated them. This requires
redeclaration checking to be implemented
separately.
Finally, to compensate for the caching that the old
operator maps were providing for imported results,
turn the operator lookup requests into cached
requests.
