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.
My experiment to improve source compatibility by also performing a
backward scan removed the SE-0286 heuristic that skipped binding
the unlabeled trailing closure to a defaulted parameter when that
would fail. Reinstate that heuristic, which makes more existing code
work with the forward-scan behavior.
This makes my source-compatibility improvements a quality-of-implementation
To better preserve source compatibility, teach the constraint
solver to try both the new forward scanning rule as well as the
backward scanning rule when matching a single, unlabeled trailing
closure. In the extreme case, where the unlabeled trailing closure
matches different parameters with the different rules, and yet both
produce a potential match, introduce a disjunction to explore both
possibilities.
Prefer solutions that involve forward scans to those that involve
backward scans, so we only use the backward scan as a fallback.
SE-0248 changes the backward-scan matching behavior for the unlabeled
trailing closure into a forward scan. In circumstances where this
could silently change the meaning of a call to a particular
function, i.e., when there are two defaulted closure parameters such
that a given closure to match either one of them, produce an warning
that describes the change in behavior. For example:
t4.swift:2:24: warning: since Swift 5.3, unlabeled trailing
closure argument matches parameter 'x' rather than parameter 'z'
trailingClosureSingle2 { $0 }
^
t4.swift:2:24: note: label the argument with 'z' to retain the
pre-Swift 5.3 behavior
trailingClosureSingle2 { $0 }
^
(z: )
t4.swift:2:24: note: label the argument with 'x' to silence this
warning for Swift 5.3 and newer
trailingClosureSingle2 { $0 }
^
(x: )
t4.swift:1:6: note: 'trailingClosureSingle2(x:y:z:)' contains
defaulted closure parameters 'x' and 'z'
func trailingClosureSingle2(x: (Int) -> Int = { $0 } , y: (Int) ->
Int = { $0 }, z: (Int) -> Int = { $0 }) {}
^ ~
This explains the (rare) case where SE-0286 silently changes the
meaning of a program, offering Fix-Its to either restore the
pre-SE-0286 behavior or silence the warning, as appropriate.
Diagnosis for invalid uses of trailing closures has been folded in
with argument-matching diagnostics, so remove all of the machinery
around the syntactic "mismatched trailing closure" logic.
The change to the forward-scanning rule regressed some diagnostics,
because we no longer generated the special "trailing closure mismatch"
diagnostic. Reinstate the special-case "trailing closure mismatch"
diagnostic, but this time do so as part of the normal argument
mismatch diagnostics so it is based on type information.
While here, clean up the handling of missing-argument diagnostics to
deal with (multiple) trailing closures properly, so that we can (e.g)
suggest adding a new labeled trailing closure at the end, rather than
producing nonsensical Fix-Its.
And, note that SR-12291 is broken (again) by the forward-scan matching
rules.
Once the first argument for a variadic function-typed parameter has been
matched, allow an unlabeled trailing closure to match, rather than
banning all uses of the unlabeled trailing closure with variadic
parameters.
The "fuzzy" forward scan matching algorithm was only applied when there
was a single, unlabeled trailing closure, but was disabled in the
presence of multiple trailing closures. Extend the "fuzzy" match to
account for multiple trailing closures, by restricting the search for
"a later parameter that needs an argument" to stop when we find a
parameter that matches the first (labeled) trailing closure.
Introsuce a new "forward" algorithm for trailing closures where
the unlabeled trailing closure argument matches the next parameter in
the parameter list that can accept an unlabeled trailing closure.
The "can accept an unlabeled trailing closure" criteria looks at the
parameter itself. The parameter accepts an unlabeled trailing closure
if all of the following are true:
* The parameter is not 'inout'
* The adjusted type of the parameter (defined below) is a function type
The adjusted type of the parameter is the parameter's type as
declared, after performing two adjustments:
* If the parameter is an @autoclosure, use the result type of the
parameter's declared (function) type, before performing the second
adjustment.
* Remove all outer "optional" types.
For example, the following function illustrates both adjustments to
determine that the parameter "body" accepts an unlabeled trailing
closure:
func doSomething(body: @autoclosure () -> (((Int) -> String)?))
This is a source-breaking change. However, there is a "fuzzy" matching
rule that that addresses the source break we've observed in practice,
where a defaulted closure parameter precedes a non-defaulted closure
parameter:
func doSomethingElse(
onError: ((Error) -> Void)? = nil,
onCompletion: (Int) -> Void
) { }
doSomethingElse { x in
print(x)
}
With the existing "backward" scan rule, the trailing closure matches
onCompletion, and onError is given the default of "nil". With the
forward scanning rule, the trailing closure matches onError, and there
is no "onCompletion" argument, so the call fails.
The fuzzy matching rule proceeds as follows:
* if the call has a single, unlabeled trailing closure argument, and
* the parameter that would match the unlabeled trailing closure
argument has a default, and
* there are parameters *after* that parameter that require an argument
(i.e., they are not variadic and do not have a default argument)
then the forward scan skips this parameter and considers the next
parameter that could accept the unlabeled trailing closure.
Note that APIs like doSomethingElse(onError:onCompletion:) above
should probably be reworked to put the defaulted parameters at the
end, which works better with the forward scan and with multiple
trailing closures:
func doSomethingElseBetter(
onCompletion: (Int) -> Void,
onError: ((Error) -> Void)? = nil
) { }
doSomethingElseBetter { x in
print(x)
}
doSomethingElseBetter { x in
print(x)
} onError: { error in
throw error
}
If the source of the "mismatch" is `Equal` constraint we can't
record a missing unwrap fix if either size is a type variable
after all of the optionals have been stripped away because
there is not enough information about what is expected behavior
until type variable gets bound.
Previously we could inadvertently split the
constraint system without realizing that a function
builder with a generic argument may allow the
closure body to reference a type variable that
connects it to the enclosing expression.
Fix this issue by checking for an unresolved
closure argument and forming an unresolved argument
conversion constraint that includes any type
variables from the function builder type.
Resolves SR-13183
Resolves rdar://problem/65695054
If it has been detected that there is an attempt to return a value
from a function without result type, let's diagnose that specifically
in cases when ternary operator is involved.
* [TypeCheckConstraints] Adjusting cases where checked casts that cannot be determined statically were producing misleading warnings
* [tests] Adding regression tests for SR-13088
* [TypeCheckConstraints] Adjusting comment and adding an extra test case for SR13035
* [TypeCheckConstraints] Fixing typos in comments
* [AST] Moving implementation of isCollection from ConstraintSystem to AST TypeBase
* [TypeCheckConstraints] Adjusting logic to verify specific conformance to stdlib collection type before emit an downcast warning
* [TypeCheckConstraints] Creating new CheckedCastContextKind::CollectionElement to be able to verify special cases within typeCheckCheckedCast for collection elements
* [TypeCheckConstraints] Adjusting logic around generic substitution to check both subtype and supertype
* [Sema] Adding isKnownStdlibCollectionType and replacing all usages contraint system method
* [TypeChecker] Reverting fixes around array element types
* [TypeChecker] Abstract logic of check for conditional requirements on TypeChecker::couldDynamicallyConformToProtocol
* [TypeChecker] Ajdustinc can conformDynamically conform and adjust review comments
* [TypeChecker] Ajusting comments and fixing typos
* [TypeChecker] Adjusting existential and archetype logic to check inside couldDynamicConform
* [TypeChecker] Adjusting minor and adding existential check into couldDynamically conform.
* [TypeChecker] Adjusting comments
* [CSDiagnostics] Adjusting MemberAccessOnOptionalBaseFailure to be able to handle key path component member base types
* [tests] Adding regression tests for SR-5688
* [CSDiagnostics] Adjusting source range to diagnose/insert the fixes in correct location
* [tests] Adjusting regression tests to handle the fixits
* [AST] Creating an helper getSourceRange function for KeyPathExpr::Component
* [ConstraintSystem] Store member base type when recording UnwrapOptionalBase fix
* [AST] Creating a new diagnostic note for removing optional from written type
* [CSDiagnostics] Adjusting logic around MemberAccessOnOptionalBaseFailure to emit the correct diagnostics and fixes
* [tests] Adjusting regression tests to add subscript and key path root cases with respective diagnostics
* [Diagnostics] Adjusting message to mention base type
* [CSDiagnostics] Better naming for method/variable that represents base source range
* [CSDiagnostics] Adjusting to use the stored base member only when member is a key path component.
* [Diagnostics] Adjusting minor typos and code
* [AST] Adjusting keypath root diagnostic note message for use unwrapped type
* [CSDiagnostics] Adjusments in MemberAccessOnOptionalBaseFailure diagnostics as per suggestion
* [tests] Adding more test cases for SR-5688
* [CSDiagnostics] Adjusting fixits for key path root and range for diagnostics
* [CSSimplify] Attempt to diagnose InsertExplicitCall for optional function return types when possible on simplifyOptionalObjectConstraint
* [tests] Adding TODO to improve the diagnostics refering to key path root infered as optional types
* [CSDiagnostics] Adjusting comments
* [CSSimplify] Adjusting logic on simplifyOptionalObjectConstraint to attempt InsertCall fix before remove unwrap
* [CSDiagnostics] Adjust the logic to use resolveType on MemberAccessOnOptionalBaseFailure construction
Currently it's possible to have a type conflict between different
requirements deduced as the same type which leads to incorrect
diagnostics. To mitigate that let's adjust how "fixed" requirements
are stored - instead of using resolved type for the left-hand side,
let's use originating generic parameter type.
Instead of special casing argument-to-parameter matching for
object literal expressions, let's allow constraint system to
lookup a witness initializer and apply it to the given set
of arguments.
This also simplifies constraint application because
`coerceCallArguments` could be used to form type-checked
argument expression.
Just like we already do for stdlib types, extend impact of missing
conformances on _known_ foundation types because it's unlikely to
be a valid suggestion to extend a foundation type with a new conformance.
