Unfortunately current approach of making a conversion independent of location
doesn't work when conversion is required for multiple arguments to the
same call because solver expects that either there are no Double<->CGFloat
conversions, or one of them has already been applied which is not the case.
The reason why locations weren't preserved in the first place is due to
how a solution is applied to AST - AST is mutated first and then, if there
are any conversions, they are applied to the already mutated version of
original AST. This creates a problem for Double<->CGFloat which depends
on an overload choice of injected call and it's impossible to find it based
on the mutated AST. But it turns out that this is only an issue in two
specific cases - conversions against contextual type and after optional injection.
This situations could be mitigated by dropping parts of the locator which are
unimportant for the Double<->CGFloat conversion - anchor in case of contextual
and `OptionalPayload` element(s) in case of optional injection.
Resolves: https://github.com/apple/swift/issues/59374
The deepest expression is the one that introduced the ambiguity into
the chain, so depth and index should be deciding factors and number of
overloads - a tie-breaker, while choosing what to diagnose.
Resolves: rdar://94360230
Previously for-in target was actually an expression target, which means
certain type-checking behavior. These changes make it a standalone target
with custom behavior which would allow solver to introduce implicit
`makeIterator` and `next` calls and move some logic from SILGen.
Fixes an oversight where `inout` -> C pointer conversion wasn't covered
by implementation of new pointer conversion semantics proposed by SE-0324.
Resolves: rdar://92583588
Accessing members on the protocol could result in existential opening and subsequence
result erasure, which requires explicit coercion if there is any loss of generic requirements.
A call to `.callAsFunction` could be injected after initializer if the type is
callable, `getCalleeLocator` should recognize that situation and return
appropriate locator otherwise if `callAsFunction` has e.g. a result builder
attached to one of its parameters the solver wouldn't be able to find it.
Resolves: rdar://92914226
The solver used to check availability attribute on the declaration
itself, a better approach is to go through `AvailableAttr::isUnavailable`
because that also covers unavailable extensions.
Resolves: rdar://92364955
The main function is different from other function resolutions. It isn't
being called from a synchronous or asynchronous context, but defines
whether the program starts in a synchronous or async context. As a
result, we should not prefer one over the other, so the scoring
mechanism shouldn't involve the async/sync score when resolving the main
function.
This patch adds a constraint solver flag to ignore async/sync context
mismatches so that we do not favor one over the other, but otherwise use
the normal resolution behavior.
`SyntacticElement` represents a statement, pattern, declaration,
condition, or expression and could originate from i.e. a closure,
a function or a result builder body.
Solver can now handle multiple different targets e.g. multi-statement
closures, result builders etc. So it's more appropriate to say that
the constraint system is too complex.
Stop pretending that an optional requirement is immutable via the `StorageImplInfo` request.
This approach has lead astray the conformance checker and may have had a negative impact
on other code paths, and it doesn't work for imported declarations because they bypass the
request. Instead, use a forwarding `AbstractStorageDecl::isSettableInSwift` method
that special-cases optional requirements.
This requires navigating the constraint system solution to retrieve the argument type of the `buildBlock` call. The comments in the code should describe what I’m doing well enough.
rdar://83846531
During normal type-checking we ignore functions that contain an error. During code completion, we want to consider them and replace all error types by placeholders so we can match up the known types.
We already do this for member types (see `getTypeOfMemberReference`). We should also do it for top-level functions.
Fixes rdar://81425383 [SR-14992]
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>
