Consider both frameworks and free floating modules imported from more
private path as SPI. This will make the compiler raise errors on public
imports of more private modules.
rdar://91904154
When emitting a symbol graph file for a module that import modules via
`@_exported import`, emits those modules' symbols as well.
SR-15753
rdar://89547374
To help maintain source-compatibility, the presence of an `await` in
top-level code to kick the top-level code over to being a concurrent
context.
This, of course, means that in the test cases that exist today, they
will go back to behaving identically to how they did before I added all
of this because they don't have any awaits in the top-level. I'll be
adding new tests to verify the differences in behavior between swift 5,
swift 6, with and without async top level enabled in the next commit.
Introduce the `@preconcurrency` attribute name for `@_predatesConcurrency`,
which has been the favored name in the pitch thread so far. Retain the
old name for now to help smooth migration.
Rather than tacking the "add `@_predatesConcurrecy` to import"
diagnostic on to the prior diagnostic as a note, make it its own
remark. Then, ensure that we only emit this remark once per source
file per imported module, so we're not overwhelming the user.
* rename the CrossModuleSerializationSetup pass to simply CrossModuleOptimization
* remove the CMO specific serializer pass. Instead run the CrossModuleSerializationSetup pass directly before the standard serializer pass.
* correctly handle shared functions (e.g. specializations)
* refactoring
When looking for a Swift module on disk, we were scanning all module search paths if they contain the module we are searching for. In a setup where each module is contained in its own framework search path, this scaled quadratically with the number of modules being imported. E.g. a setup with 100 modules being imported form 100 module search paths could cause on the order of 10,000 checks of `FileSystem::exists`. While these checks are fairly fast (~10µs), they add up to ~100ms.
To improve this, perform a first scan of all module search paths and list the files they contain. From this, create a lookup map that maps filenames to the search paths they can be found in. E.g. for
```
searchPath1/
Module1.framework
searchPath2/
Module1.framework
Module2.swiftmodule
```
we create the following lookup table
```
Module1.framework -> [searchPath1, searchPath2]
Module2.swiftmodule -> [searchPath2]
```
We noticed some Swift clients rely on the serialized search paths in the module to
find dependencies and droping these paths altogether can lead to build failures like
rdar://85840921.
This change teaches the serialization to obfuscate the search paths and the deserialization
to recover them. This allows clients to keep accessing these paths without exposing
them when shipping the module to other users.
We've recently added the -experimental-hermetic-seal-at-link compiler flag,
which turns on aggressive dead-stripping optimizations and assumes that library
code can be optimized against client code because all users of the library
code/types are present at link/LTO time. This means that any module that's
built with -experimental-hermetic-seal-at-link requires all clients of this
module to also use -experimental-hermetic-seal-at-link. This PR enforces that
by storing a bit in the serialized module, and checking the bit when importing
modules.
Fix an issue where `if #available(...)` conditions were ignored in
emit-module-separately builds or when skipping non-inlinable function
bodies.
To handle functions for which parsing is delayed but type-checking is
not delayed, move up building the delayed TRC to the
TypeCheckFunctionBodyRequest service.
rdar://83166742
The check for implementationOnly imports was already done for types, but it was missing for functions.
Fixes a crash when implementationOnly-importing a C module.
https://bugs.swift.org/browse/SR-15048
rdar://81701218
Many, many, many types in the Swift compiler are intended to only be allocated in the ASTContext. We have previously implemented this by writing several `operator new` and `operator delete` implementations into these types. Factor those out into a new base class instead.
