`repairFailures` needs a special case when l-value conversion is
associated with a result type of subscript setter because otherwise
it falls through and treats result type as if it's an argument type,
which leads to crashes.
Resolves: rdar://84580119
Adds support for parameter types like `[T?]` or `[(T, U?)]`,
and relaxes restriction on same-type generic parameters.
A same-type requirement is acceptable if it only includes
in-scope generic parameters and concrete types i.e. `T.X == Int`
if accepted if `T` is referenced only by a parameter default
expression is being applied to.
This reverts commit 6e7fff7e65283ae9b25116fa6b75ba92fd2f2a58. The
asymmetry between opening for optional parameters and optional
arguments is surprising enough that we're currently opting not to
allow them.
Ensure that we only open existentials in an argument when the corresponding
parameter's type is a generic parameter that is only used in covariant
positions, because either invariant or contravariant uses mean that we
won't be able to type-erase other uses of that parameter. This mirrors
the requirement placed when opening existentials as a member of protocol
type.
When calling a generic function with an argument of existential type,
implicitly "open" the existential type into a concrete archetype, which
can then be bound to the generic type. This extends the implicit
opening that is performed when accessing a member of an existential
type from the "self" parameter to all parameters. For example:
func unsafeFirst<C: Collection>(_ c: C) -> C.Element { c.first! }
func g(c: any Collection) {
unsafeFirst(c) // currently an error
// with this change, succeeds and produces an 'Any'
}
This avoids many common sources of errors of the form
protocol 'P' as a type cannot conform to the protocol itself
which come from calling generic functions with an existential, and
allows another way "out" if one has an existention and needs to treat
it generically.
This feature is behind a frontend flag
`-enable-experimental-opened-existential-types`.
In an async context, trying to pass a non-`@Sendable` function to an `@Sendable` parameter or trying to assign a `@MainActor` method to a non-`@MainActor`-typed variable were hard errors. We now think that this a mistake for `@preconcurrency` APIs in Swift 5 mode, as it hinders retroactive adoption of `@Sendable` and `@MainActor` by libraries.
This PR weakens these errors to warnings *only* when the decl which contains the attribute in its type signature is `@preconcurrency` and *only* when in Swift 5 mode (with or without -warn-concurrency). For non-`@preconcurrency` decls, it is still an error.
Fixes <rdar://88703266>.
This was only intended to preserve compatibility
for cases where the constraint system may have
previously accepted invalid code. Drop it in Swift 6
mode such that invalid collection coercions become
errors.
We currently permit (but warn on) coercions of
collections with unrelated element types in
certain cases. This is done in an effort to preserve
compatibility with pre-5.3 compilers that may have
allowed such code to compile due to dropping
constraints while solving.
This is limited to collection coercions as we
emit somewhat reasonable code for them that
performs a force cast of the elements at runtime.
However, it turns out that in the case of collection
literals, we peephole the element conversions in
CSApply, leading to codegen crashes. As such,
narrow down the condition of this compatibility
logic to not apply to collection literals, as this
never would have compiled properly.
rdar://88334481
If argument matching fails in diagnostic mode, it can only mean
that it couldn't find any viable fixes to attempt, so let's try
injecting `.callAsFunction` when appropriate to help diagnose
possible mismatches related to ambiguous syntax.
In situations like `T(...) { ... }` where `T` is a callable type,
it's not immediately clear whether trailing closures are associated
with `.init` of `T` or implicit `.callAsFunction`. So if constructor
didn't match trailing closures, let's attempt to split them off and
form an implicit `.callAsFunction` call with them as a fallback.
Opened archetypes can be created in the constraint system, and the
existential type it wraps can contain type variables. This can happen
when the existential type is inferred through a typealias inside a
generic type, and a member reference whose base is the opened existential
gets bound before binding the generic arguments of the parent type.
However, simplifying opened archetypes to replace type variables is
not yet supported, which leads to type variables escaping the constraint
system. We can support cases where the underlying existential type doesn't
depend on the type variables by canonicalizing it when opening the
existential. Cases where the underlying type requires resolved generic
arguments are still unsupported for now.
Nested archetypes are represented by their base archetype kinds (primary,
opened, or opaque type) with an interface type that is a nested type,
as represented by a DependentMemberType. This provides a more uniform
representation of archetypes throughout the frontend.
Introduce a new primitive operation on opaque type archetypes that
canonicalizes a type within the environment of the opaque type
archetype without building the environment itself. Use it when matching
opaque archetype types in the solver.
Insert an implicit conversion from pack types to tuples with equivalent parallel structure. That means
1) The tuple must have the same arity
2) The tuple may not have any argument labels
3) The tuple may not have any variadic or inout components
4) The tuple must have the same element types as the pack
The heart of this patchset: An inference scheme for variadic generic functions and associated pack expansions.
A traditional variadic function looks like
func foo<T>(_ xs: T...) {}
Along with the corresponding function type
<T>(T [variadic]) -> Void
which the constraint system only has to resolve one two for. Hence it opens <T> as a type variable and uses each argument to the function to try to solve for <T>. This approach cannot work for variadic generics as each argument would try to bind to the same <T> and the constraint system would lose coherency in the one case we need it: when the arguments all have different types.
Instead, notice when we encounter expansion types:
func print<T...>(_ xs: T...)
print("Macs say Hello in", 42, "different languages")
We open this type as
print : ($t0...) -> ($t0...)
Now for the brand new stuff: We need to create and bind a pack to $t0, which will trigger the expansion we need for CSApply to see a coherent view of the world. This means we need to examine the argument list and construct the pack type <$t1, $t2, $t3, ...> - one type variable per argument - and bind it to $t0. There's also the catch that each argument that references the opened type $t0 needs to have the same parallel structure, including its arity. The algorithm is thus:
For input type F<... ($t0...), ..., ($tn..) ...> and an apply site F(a0, ..., an) we walk the type `F` and record an entry in a mapping for each opened variadic generic parameter. Now, for each argument ai in (a0, ..., an), we create a fresh type variable corresponding to the argument ai, and record an additional entry in the parameter pack type elements corresponding to that argument.
Concretely, suppose we have
func print2<T..., U...>(first: T..., second: U...) {}
print2(first: "", 42, (), second: [42])
We open print2 as
print2 : ($t0..., $t1...) -> Void
And construct a mapping
$t0 => <$t2, $t3, $t4> // eventually <String, Int, Void>
$t1 => <$t5> // eventually [Int]
We then yield the entries of this map back to the solver, which constructs bind constraints where each => exists in the diagram above. The pack type thus is immediately substituted into the corresponding pack expansion type which produces a fully-expanded pack type of the correct arity that the solver can actually use to make forward progress.
Applying the solution is as simple as pulling out the pack type and coercing arguments element-wise into a pack expression.
When evaluating whether code is within a closure that uses concurrency
features, use the type of the closure as it's known during type checking,
so that contextual information (e.g., it's passed to a `@Sendable` or
`async` parameter of function type) can affect the result. This
corrects the definition for doing strict checking within a minimal
context for the end result of the type-check, rather than it's initial
state, catching more issues.
Fixes SR-15131 / rdar://problem/82535088.
The new type, called ExistentialType, is not yet used in type resolution.
Later, existential types written with `any` will resolve to this type, and
bare protocol names will resolve to this type depending on context.
