All but 7 tests now passing. Those 7 tests either do not refer to these circumstances or do not seem to pass even when modified to accept type specifications.
`return` statement withot an expression automatically gets an
implicit `()` which is allowed to be converted to types like
`()?` and `Any` or `Any?`. Let's remove a too strict assertion
that expected a contextual type to always be `()?` even
through in reality any type that `()` is convertible to is valid.
Resolves: rdar://152553143
Fix "affected" declaration computation to handle situations when
a generic type happens to be in a closure parameter position.
Resolves: rdar://150068895
The problem detection logic currently expects `generic argument #<N>`
location to always be associated with two generic types, but that
is not always the case, this locator element is sometimes used for
i.e. optional object types and pointer `Pointee` type when types
appear in argument positions. This needs to be handled specifically.
Resolves: rdar://82971941
Without contextual information it won't be possible to bind a missing
member to a concrete type later, so let's bind them eagerly and propagate
placeholders outward.
Resolves: rdar://152021264
Resolves: https://github.com/swiftlang/swift/issues/81770
`@autoclosure` is associated with a parameter, we use argument mismatch fix
to diagnose missing explicit calls as well as any mismatches in that position.
Resolves: rdar://110527062
We don't want to do that in general because injection should happen
only in one place but Void is special because it allows conversions
in that position.
- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
Previously, missing return diagnostics for unreachable subscripts
differed from the treatment unreachable functions received, leading to
inconsistent diagnostic behavior. This change removes the responsibility
for handling the relevant diagnostics from the AST code, in favor of the
diagnostics implemented via the SIL optimizer. Additionally, where the
AST-generation code would previously have diagnosed a missing return for
an implicit empty getter, it will now admit as valid, deferring the
missing return diagnostics to the later SIL passes.
Track the implied result exprs in the constraint
system, and allow arbitrary propagation of
implied results down if/switch expression
branches. This is required for allowing implied
results in non-single-expression closures.
We accepted unnamed closure parameters if the type was an array literal, dictionary literal, tuple or function (because the `[` or `(` starting the type was sufficient to disambiguate the type from the parameter’s name). This was never an accepted syntax and we should disallow it.
Checking type variables is no longer necessary because constraint
system now stores types of all closures it encountered, this makes
detection logic more reliable as well.
Resolves: rdar://112426330
Move out-of-place SingleValueStmtExpr checking into
`performSyntacticExprDiagnostics`, to ensure we
catch all expressions. Previously we did the walk
as a part of Decl-based MiscDiagnostics, but it
turns out that can miss expressions in property
initializers, subscript default arguments, and
custom attrs.
This does mean that we'll now no longer diagnose
out-of-place if/switch exprs if the expression
didn't type-check, but that's consistent with the
rest of MiscDiagnostics, and I don't think it will
be a major issue in practice. We probably ought to
consider moving this checking into PreCheckExpr,
but that would require first separating out
SequenceExpr folding, which has other consequences,
and so I'm leaving as future work for now.
`test/Constraints/interpolation_segments.swift` has been removed
because interpolations are now type-checked together with their
context, so the separate type-checking test no longer applies.
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
SE-0110 allows tuple slat between function types. The solver needs to
account for that when trying to infer parameter types from context
while resolving a closure in order to propagate types and speed up
type-checking.
Resolves: https://github.com/apple/swift/issues/62390
If all solutions point to the same overload choice that needs
re-labeling it's safe to diagnose it as if there was no ambiguity
because the call site is static.
Warnings cannot lead to failures or ambiguity so let's remove
them from consideration when attempting to diagnose ambiguity
potentially caused by the same fix appearing in different
solutions.
Resolves: rdar://81228501
When inference is determining bindings of a type variable that represents
an overload set (e.g. member or operator reference), let's not consider
it as delayed due to presence of `ApplicableFunction` constraint since
argument/result type inference depends on overload set but not vice versa.
Resolves: rdar://78917861
Currently ambiguity notes attached to a candidate only mention
expected type and its position. To improve clarify of such notes
it's useful to print argument type as well since it's not always
clear what it is at the first glance at the code.
Resolves: SR-14634
Resolves: rdar://78224323
