Re-introduce unsolved member constraint when optional object is
a type variable or member until it's bound, otherwise it's impossible
to tell whether unwrapped base would have a member or not.
Instead, ensure we walk into expressions in
SyntacticDiagnosticWalker, allowing
`performStmtDiagnostics` to be called there for
all statements present in the target. This avoids
a case where we'd double diagnose.
While here, inherit the walker from
BaseDiagnosticWalker.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of opaque types, instead
of disabling availability checking.
Use `preCheckTarget` to pre-check the body,
allowing us to replace `PreCheckResultBuilderRequest`
with a request that only checks the brace for
ReturnStmts.
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
Previously we would wait until CSApply, which
would trigger their type-checking in
`coercePatternToType`. This caused a number of
bugs, and hampered solver-based completion, which
does not run CSApply. Instead, form a conjunction
of all the ExprPatterns present, which preserves
some of the previous isolation behavior (though
does not provide complete isolation).
We can then modify `coercePatternToType` to accept
a closure, which allows the solver to take over
rewriting the ExprPatterns it has already solved.
This then sets the stage for the complete removal
of `coercePatternToType`, and doing all pattern
type-checking in the solver.
This means two things:
- transformed closures behave just like regular multi-statement closures
- It's now possible to pass partially resolved parameter types into
the closure which helps with diagnostics.
When matching a result builder in the constraint system, the closure has already been pre-checked so we don’t need to pre-check it again. Also, we can continue type checking even if the closure contained an `ErrorExpr` since result builders are now type checked like regular closures.
This means two things:
- transformed closures behave just like regular multi-statement closures
- It's now possible to pass partially resolved parameter types into
the closure which helps with diagnostics.
The impact should be very high because the whole body is skipped
if the builder does not support some of the operations, otherwise
the fix would interfere with result builders that do support
operations but have syntactic issues in the body.
Resolves: rdar://89880662
If a placeholder appears on one of the side of tuple element matching
conversion, consider that conversion to be solved, because the actual
error is related to the placeholder.
With AST transform enabled by default most of the previously
invalid declarations became valid (due to SE-0373 being implemented
only for AST transform).
In cases like `case .test(_)` it might not be possible to
establish a type of `_` and hole cannot be propagated to
it from context if condition of switch is incorrect, so
`_` just like a named pattern should be allowed to become
a hole.
Resolves: rdar://96997534
Augment the constraint solver to fallback to implicit `~=` application
when member couldn't be found for `EnumElement` patterns because
`case` statement should be able to match enum member directly, as well
as through an implicit `~=` operator application.
If underlying type of an optional chain has been marked as a hole,
e.g. due to a reference to an invalid or missing member, let's
propagate that information to object type of an optional that
represents a result of an optional chain.
Resolves: rdar://80941497
`SolutionApplicationTargetsKey` was constructing pattern binding
entries with incorrect `kind`, which led to crashes for pattern
bindings with multiple initialized entries.
If lookup failed to find a member for a pattern match, let's bind
type variable representing such member to a hole right away, otherwise
there is a risk of missing other potential hole locations in pattern
function type (arguments + result type) because pattern matching
doesn't use 'applicable function' constraint.
Resolves: rdar://65667992
While determining whether result builder body is correct, allow
pre-check phase to look into single-statement closures because
their bodies participate in type-check and would fail constraint
generation if they contain `ErrorExpr`s, so it's better to determine
that the body is invalid early and skip result builder application.
Resolves: rdar://79746785
Not all of the pre-check errors could be diagnosed by re-running
`PreCheckExpression` e.g. key path expressions are mutated to
a particular form after an error has been produced.
To make the behavior consistent, let's allow pre-check to emit
diagnostics and unify pre-check and constraint generation fixes.
Resolves: rdar://77466241
Let's make use of a newly added "disable for performance" flag to
allow solver to consider overload choices where the only issue is
missing one or more labels - this makes it for a much better
diagnostic experience without any performance impact for valid code.
We assume that presence of `ErrorExpr` means that the problem has
been diagnosed early (i.e. by parser), so the fix is going to return
`true` if diagnostic engine has emitted an error.
Resolves: rdar://76246526
If closure parameter has an explicit type, type resolution
would diagnose the issue and cache the resulting error type for
future use. Invalid types currently fail constraint generation,
which doesn't play well with result builders because constraint
generation for their bodies happens during solving.
Let's handle invalid parameters gracefully, replace them with
placeholders and let constraint generation proceed.
Resolves: rdar://75409111
Since labels are considered part of the name, mismatches in labeling
should be invalidate overload choices. Let's prefer an overload with
correct labels but incorrect types over the one with incorrect labels.
This also means that it's possible to restore performance optimizations
related to early filtering in diagnostic mode, which is important for
deeply nested code i.e. SwiftUI views.
