We know this is where the issue is so we can immediately bind to a hole,
ensuring we don't produce unnecessary downstream diagnostics from
things we can't infer.
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
We set an original expression on ErrorExpr for cases where we have
something semantically invalid that doesn't fit into the AST, but is
still something that the user has explicitly written. For example
this is how we represent unresolved dots without member names (`x.`).
We still want to type-check the underlying expression though since
it can provide useful diagnostics and allows semantic functionality
such as completion and cursor info to work correctly.
rdar://130771574
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
Make sure `CouldNotInferPlaceholderType` can
produce a diagnostic for a `PlaceholderType`
locator element, and avoid emitting an extra
diagnostic for a placeholder type in an invalid
position.
Stored `let` properties of a struct, class, or actor permit
'inout' modification within the constructor body after they have been
initialized. Tentatively remove this rule, only allowing such `let`
properties to be initialized (assigned to) and not treated as `inout`.
Fixes rdar://127258363.
Inference cannot be allowed in cases where both sides are type
variables and optional type is l-value capable because it results
in binding "optional" to an optional type and later discovering
a contextual type that is l-value optional i.e. if "optional type"
is resolved by selecting subscript overload.
* Revert "Revert count(where:)"
This reverts commit 779ea19a6a.
Now that SE-0220 has been re-accepted, this adds the `count(where:)`
Sequence method to the standard library.
Inference cannot be allowed in cases where both sides are type
variables and optional type is l-value capable because it results
in binding "optional" to an optional type and later discovering
a contextual type that is l-value optional i.e. if "optional type"
is resolved by selecting subscript overload.
Failure of an argument to AnyHashable parameter to conform to Hashable
protocol should be detected in `simplifyConformsToConstraint` and fixed
there.
Doing so requires impact assessment adjustment because regular conformance
requirements have default impact of 1, this is going to have argument
impact of 2 not avoid clashing with other failures.
Previously we relied on `TupleTypeElt::getType`
returning an `InOutType` to fail the tuple type
matching logic. Instead, add logic to reject any
inout arguments up-front with a more specific
diagnostic.
Also, while we're here, strip the `_const`
parameter flag, as it's not something that needs
to be considered for tuple construction.
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
I missed this case when previously improving the
logic here. As it turns out, using the raw anchor
as the root expression from which to derive parent
information is insufficient. This is because it
may not capture relevant parent exprs not a part
of the fix locator.
Instead, pass down a function that can be used to
derive the parent expressions from the constraint
system's own parent map. Also make sure to assign
to `expr` for the UnresolvedMemberChainResultExpr
case to make sure we correctly check for it as a
sub-expression.
Finally, now that we're looking at more parent
exprs, add logic to handle `try` and `await`
parents, as well as ClosureExprs and
CollectionExprs. I couldn't come up with a test
case for CollectionExpr, as we emit different
diagnostics in that case, but it's probably better
to tend on the side of being more future proof
there.
rdar://81512079
Such implicit tuples may be used to represent
argument lists for e.g binary expressions, and as
such shouldn't be considered as parent exprs that
satisfy the role of parentheses.
Also fix the callers to use the raw anchor as the
root expression they pass to provide an accurate
parent map. This requires sinking the
UnresolvedMemberChainResultExpr handling logic into
`getPrecedenceParentAndIndex`.
rdar://81109287
