[Module Aliasing] Modify module loaders to use module 'real name' (physical name on-disk) when loading, since it can be different from 'name' if module aliasing is used. Also use the 'real name' to add/retrieve loaded modules in ASTContext. Resolves rdar://83591943.
* Fix unnecessary one-time recompile of stdlib with -enable-ossa-flag
This includes a bit in the module format to represent if the module was
compiled with -enable-ossa-modules flag. When compiling a client module
with -enable-ossa-modules flag, all dependent modules are checked for this bit,
if not on, recompilation is triggered with -enable-ossa-modules.
* Updated tests
These kinds of modules differ from `SwiftTextual` modules in that they do not have an interface and have source-files.
It is cleaner to enforce this distinction with types, instead of checking for interface optionality everywhere.
By default avoid imploding params that have parameter
flags, but carve out exceptions for ownership flags,
which can be thunked, and `@_nonEphemeral` which can
be freely dropped without issue.
Remove the canonicalVararg parameter and
CanParamArrayRef wrapper. Almost none of the
callers want canonicalVararg, and the one that
does calls `getCanonicalType` on the result
anyway.
Override checking checks if the derived declaration's generic
signature is compatible with the base, but it does this after
doing a bunch of other checks which feed potentially invalid
type parameters to generic signature queries.
Now that the requirement machine is stricter about this kind
of this, re-organize some code to get around this.
Unfortunately this regresses a diagnostic, because we reject
candidates with mismatched generic requirements earlier in
the process.
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.
We used to represent the interface type of variadic parameters directly
with ArraySliceType. This was awfully convenient for the constraint
solver since it could just canonicalize and open [T] to Array<$T>
wherever it saw a variadic parameter. However, this both destroys the
sugaring of T... and locks the representation to Array<T>. In the
interest of generalizing this in the future, introduce
VariadicSequenceType. For now, it canonicalizes to Array<T> just like
the old representation. But, as you can guess, this is a new staging
point for teaching the solver how to munge variadic generic type bindings.
rdar://81628287
* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
When looking up a conformance to Sendable fails, implicitly create a
"missing" builtin conformance. Such conformances allow type checking
to continue even in the presence of Sendable-related problems.
Diagnose these missing conformances when they are used in an actual
program, as part of availability checking for conformances and when we
are determining Sendability. This allows us to decide between an
error, a warning, and suppressing the diagnostic entirely without
affecting how the program is compiled. This is a step toward enabling
selective enforcement of Sendable.
Part of rdar://78269348.
The dependency scanner's cache persists across different queries and answering a subsequent query's module lookup with a module not in the query's search path is not correct.
For example, suppose we are looking for a Swift module `Foo` with a set of search paths `SP`.
And dependency scanner cache already contains a module `Foo`, for which we found an interface file at location `L`. If `L`∉`SP`, then we cannot re-use the cached entry because we’d be resolving the scanning query to a filesystem location that the current scanning context is not aware of.
Resolves rdar://81175942
