Such existential arguments will already meet the requirements of a
generic function they are passed to, but would change runtime
semantics. Therefore, don't open the existential in such cases.
When we open an existential argument in a call to a generic function,
type-erase contravariant uses of that opened existential in subsequent
parameters. This primarily impacts closure parameters, where we want
the closure to be provided with an existential parameter type rather
than permit the parameter to have opened existential type. This
prevents the opened existential type from being directly exposed in
the type system.
Note that we do not need to perform this erasure when the argument is
a reference to a generic function, because there it is suitable to
infer that the generic arguments are the opened archetypes. This
subsumes the use case for `_openExistential`.
When solving for code completion, we weren't disabling overloads because the call might be malfored in the presence of a code completion token (because the user is only now writing the function call). But this logic doesn't apply to function calls that don't even involve the code completion token, which happens if completing in result builders.
I am hoping that this significantly improves code completion performance inside result builders.
This hooks up call argument position completion to the typeCheckForCodeCompletion API to generate completions from all the solutions the constraint solver produces (even those requiring fixes), rather than relying on a single solution being applied to the AST (if any).
Co-authored-by: Nathan Hawes <nathan.john.hawes@gmail.com>
Represent this in much the same way that collections do by creating an opaque value representing the source argument, and a conversion expression representing the destination argument.
Add deep equality typing rules for
P =~= Q, T == X, U == Y, V == Z, ...
--------------------------------
P<T, U, V, ...> == Q<X, Y, Z, ...>
Also add existential matching rules to discharge the constraints on parameterized protocols against concrete types. e.g.
class C: P { typealias T = Int }
func foo<T>(_ x: P<T>) {}
foo(C())
Should cause T to unify against C.T = Int
This ensures that opened archetypes always inherit any outer generic parameters from the context in which they reside. This matters because class bounds may bind generic parameters from these outer contexts, and without the outer context you can wind up with ill-formed generic environments like
<τ_0_0, where τ_0_0 : C<T>, τ_0_0 : P>
Where T is otherwise unbound because there is no entry for it among the generic parameters of the environment's associated generic signature.
Augment the constraint solver to fallback to implicit `~=` application
when member couldn't be found for `EnumElement` patterns because
`case` statement should be able to match enum member directly, as well
as through an implicit `~=` operator application.
`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
