Intro the concept of library access or distribution level to identify
layers of libraries and report public imports of private libraries from
public ones.
rdar://62934005
When requestifying the synthesis of the main function for the type
annotated @main via SynthesizeMainFunctionRequest, what were previously
were bailouts from AttributeChecker::visitMainTypeAttr had to become
returns of nullptr from SynthesizeMainFunctionRequest::evaluate.
Consequently, AttributeChecker::visitMainTypeAttr must check whether
synthesis actually succeeded before proceeding to to register the main
decl for a file.
In simple cases, this happened to work because
SourceFile::registerMainDecl would return early if the decl being
registered was the same as the already registered main decl and in
particular if the decl being registered was nullptr and the previously
registered one was nullptr as well. When, however, there are multiple
types annotated @main, if a function is successfully synthesized for one
type but synthesis fails for the second, an attempt will be made to
register nullptr as the main decl and will move past the check at the
beginning of SourceFile::registerMainDecl, resulting in a crash.
Here, we bail from AttributeChecker::visitMainTypeAttr if function
synthesis fails and add an assert to SourceFile::registerMainDecl that
the provided decl is non-null.
rdar://75547146
Using `-module-abi-name` for the `_Concurrency` module breaks older
Swift compilers. Instead, hard-code that "Swift" is the ABI name of the
"_Concurrency" module in the compiler to dodge the problem.
There is a known issue with module interfaces where a type with the same name as a module will disrupt references to types in that module. Fully fixing it will require a new language feature (SR-898) which is not yet available. In the meantime, module interfaces support a workaround flag (“-Xfrontend -module-interface-preserve-types-as-written”) which prints an alternate form that usually works. However, you have to know to add this flag, and it’s not obvious because nothing breaks until a compiler tries to consume the affected module interface (or sometimes even one of its clients).
This commit emits a warning during module interface emission whenever the module interface either imports a type with the same name as the module being built, or declares a type with the same name as a visible module. This lets the user know that the type may cause problems and they might need to implement a workaround.
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
Rename ImportedModuleDesc to AttributedImport and make it a template that’s parameterized on the representation of the module. This will allow us to reduce duplicated representations of “abstract” ImportDecls.
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.
