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
Give BuiltinProtocolConformance a generic signature, which can be used to
describe the generic parameters used within the builtin conformance, e.g.,
`<T1, T2, T3>` for a tuple type `(T1, T2, T3)`. Also store the
conditional requirements as trailing objects, requiring them to be
precomputed by whatever builds the conformances. Together, this means
that builtin protocol conformances act like normal conformances with
respect to conditional requirements and substitutions: they will be
defined generically, then a specialized conformance will be layered on
top to provide the substitutions.
Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
This was for test coverage before I had any queries ported over, just to
make sure that the completion procedure worked.
Now that all the GenericSignature queries have been ported over, we don't
need this since we're going to create all the RequirementMachines anyway.
Parse and provide semantic checking for '@unchecked Sendable', for a
Sendable conformance that doesn't perform additional semantic checks
for correctness.
Part of rdar://78269000.
The `compare_lower` API was replaced with `compare_insensitive` in llvm
commit 2e4a2b8430aca6f7aef8100a5ff81ca0328d03f9.
git clang-format ran.
(cherry picked from commit aca2de95ee)
Treat actors as being semantically `final` throughout the type checker.
This allows, for example, a non-`required` initializer to satisfy a
protocol requirement.
We're leaving the ABI open for actor inheritance should we need it.
Addresses rdar://78269551.
Based on the discussion in the first review of the global actors
proposal, introduce a `GlobalActor` protocol that describes types that
can be global actors. Introduce this protocol, make `@globalActor`
types implicitly conform to it, and remove all of the bespoke
validation logic that was used to check the "shared" member.
Addresses rdar://79339591
The notion of "actor-isolated" currently exists at the declaration level.
For functions, it is going to be captured in the function type itself,
where 'self' is declared to be 'isolated'. Model isolation both
ways: the 'self' of a method that is isolated to an actor instance
will be 'isolated' as well.
We are still using declaration-based checking of actor isolation.
However, by mirroring this information we can move more incrementally
over to doing checking based on 'isolated' parameters.
