This flag biases the overload checker in favor of selecting an
asynchronous main function over a synchronous main. If no asynchronous
main function exists, a synchronous one will still be selected.
Likewise, if the flag is not passed and there are only asynchronous main
functions available, the most specific asynchronous main function will
still be selected.
`typeEraseExistentialSelfReferences` shouldn't account for
contextual signature because that signature could have
generic parameters of it's own unrelated to the reference
which would be located before generic parameters of the
member, e.g. when the code is located in a protocol extension,
which invalidates the assumption that `Self` is located at
depth = 0, index = 0.
Resolves: rdar://91110069
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`.
Since constraint solver can now handle statements, patterns, and declarations,
it's possible to that ambiguity could be detected in a non-expression context,
for example - pattern matching in switch statements. Augment `diagnoseAmbiguity`
to accept overloads with non-expression anchors and diagnose them in order of
their appearance in a solution.
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>
We don't want to pass in the outer generic signature here.
The base type's constraint type is written in terms of archetypes,
and we run generic signature queries against it with types appearing
in the protocol member. Since the protocol member has Self at
depth 0, index 0, prepending the outer generic signature to the
opened existential signature would produce incorrect results.
We used to concatenate the DeclContext's generic signature with the
protocol requirement's signature, then look for occurrences of the
first generic parameter from the DeclContext's signature in the
requirement's type.
This almost worked, except when the first generic parameter from the
DeclContext's signature didn't conform to a protocol referenced by
an associated type. In that case, we would falsely report that there
are no 'Self' references.
Note that the CHECK lines in test/SILGen/witnesses_class.swift change
to what they were before 01d9d61cc8.
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.
It's a convenient way to use existing logic for default argument inference
because suhc inference cannot open whole signature but only conformance
and layout constraints associated generic parameters used in a particular
parameter position.
If an overload locator couldn't be simplified to its anchor, fallback to
the anchor of the locator instead. Also add an assert so that we can
track down whether this is actually valid or not.
Resolves rdar://89097800.
An opaque type is only invariant with respect to the existential Self
when the constraints on the opaque type involve Self. Such constraints
are not expressible in the type-erased value, so treat them as
invariant. This loosens the restriction on using members of protocol
type that return an opaque type, such that (e.g.) the following is
still well-formed:
protocol P { }
protocol Q { }
extension P {
func getQ() -> some Q { ... }
}
func test(p: any P) {
let q = p.getQ() // formerly an error, now returns an "any Q"
}
However, this does not permit uses of members such as:
extension P {
func getCollection() -> some Collection<Self> { ... } // error
}
because the type system cannot express the corresponding existential
type `any Collection<Self>`.
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`.
When we are within a closure that is not required to be asynchronous
(i.e., it has no `await` in it), make sure that we prefer synchronous
functions to asynchronous ones, even if this closure will later be
converted to `async` and the constraint system knows that.
Fixes rdar://88692889.
