Avoid filtering overloads for calls which have code completion
token as an argument, that would always undesired results,
because such calls could be missing arguments before or after
the token.
We want to look for protocols at the top level, and not names visible from
the function body. Previously we were passing the function's parent
DeclContext and the source location of the parameter, but this will no
longer work, so pass the SourceFile and an empty source location instead.
Currently its impact is set to be less than that of a conversion fix,
which is incorrect. Let's adjust that and increase it even farther for
cases where base is `Any` or `AnyObject`. We couldn't do it for `Any`
before because it was used to represent type holes, but it's no longer
the case.
Resolves: rdar://problem/68155466
If base type of a unresolved member reference couldn't be determined
(represented as a hole type), before recording a fix about lack of
contextual information, let's make sure that hole originated in either
base or result type of this reference, otherwise the problem is
contextual e.g. generic parameter, which supposed to act as contextual
type for a reference, couldn't be inferred.
If the right-hand side (destination) of value-to-pointer conversion
is incorrect e.g. base type of member is a hole, let's record
a generic "invalid conversion" failure.
Resolves: rdar://problem/68254165
We previously were not properly handling the diagnostics for using an rvalue implicit member on the left hand side of an assignment. This adds the proper handling and extends it for member chains.
In order to give unresolved member chain result types visibility in the AST, we inject an implicit ParenExpr in CSGen that lives only for the duration of type checking, and gets removed during solution application.
Remove the tracking of unresolved base types from the constraint system, and place it entirely within the generation phase. We have other ways of getting at the base types after generation.
Instead of using `UnresolvedType` as a placeholder for a type hole,
let's switch over to a dedicated "rich" `HoleType` which is capable
of storing "originator" type - type variable or dependent member
type which couldn't be resolved.
This makes it easier for the solver to determine origins of
a hole which helps to diagnose certain problems better. It also
helps code completion to locate "expected type" of the context
even when it couldn't be completely resolved.
Fix is anchored on a `BraceStmt` associated with an invalid closure.
It's diagnosing the problem by calling `ConstraintSystem::preCheckExpression`
for all expressions in the body without suppressing errors.
ConstraintSystem::mergeEquivalenceClasses.
Most callers don't use the default, and it's important to consider
the value of this argument for each call to mergeEquivalenceClasses.
when we have an optional type. This uncovered an error with unresolved member lookup where we allowed an unresolved value member constraint to fail if lookup failed in an optional type wrapping a type variable.
This resolves SR-13357.
an iterator range and a callback to get the type.
This allows callers to lazily compute the input types to join rather
than constructing an array first. The old addJoinConstraint is now
a wrapper for this new overload.
Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
This heuristic merges type variables for literal expressions of the same
kind. This is valid because such type variables will have the same
set of constraints on them, and must be bound to the same type.
Solver should do more checking upfront before recording
`force downcast` fix, to make sure that it's indeed always
applicable when recorded, otherwise it would be possible
to misdiagnose or omit diagnostics in certain situations.
Resolves: rdar://problem/65254452
Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
Add `async` to the type system. `async` can be written as part of a
function type or function declaration, following the parameter list, e.g.,
func doSomeWork() async { ... }
`async` functions are distinct from non-`async` functions and there
are no conversions amongst them. At present, `async` functions do not
*do* anything, but this commit fully supports them as a distinct kind
of function throughout:
* Parsing of `async`
* AST representation of `async` in declarations and types
* Syntactic type representation of `async`
* (De-/re-)mangling of function types involving 'async'
* Runtime type representation and reconstruction of function types
involving `async`.
* Dynamic casting restrictions for `async` function types
* (De-)serialization of `async` function types
* Disabling overriding, witness matching, and conversions with
differing `async`
This approach, suggested by Xiaodi Wu, provides better source
compatibility for existing Swift code, by breaking ties in favor of the
existing Swift semantics. Each time the backward-scan rule is needed
(and differs from the forward-scan result), we will produce a warning
+ Fix-It to prepare for Swift 6 where the backward rule can be
removed.
