The original bug was a crash-on-invalid with a missing '}', but it
actually exposed a bug with nested protocols (SE-0404) and another
long-time bug.
- Whatever we do, we should skip this for protocols because their 'Self'
parameter is not bound from context.
- getTrailingWhereClause() is not the right proxy for "has a generic
signature different than its parent", in particular it doesn't
round-trip through serialization. Instead, just compare generic
signatures for pointer equality in the early return check.
The second change is source-breaking because it was possible to
write a nested type with a `where` clause and use it contradicting
its requirements across a module boundary.
Fixes rdar://113103854.
Previously we would only do source ordering for
ClosureExprs, but other conjunctions need to have
their source location taken into account too, in
order to make sure we don't try and type-check e.g
a TapExpr in a second closure before we type-check
the first closure.
Also while here, switch to `std::min_element`
instead of sorting, and treat invalid source
locations as incomparable.
rdar://113326835
If type variable we are about to bind represents a pack
expansion type, allow the binding to happen regardless of
what the \c type is, because contextual type is just a hint
in this situation and type variable would be bound to its
opened type instead.
Resolves: rdar://112617922
The progress on variadic generics means we can now implement useful
witnesses in a tuple conformance. The feature remains very incomplete
though, today we crash in SILGen.
This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
This should no longer be needed now that we check for a code
completion token when increasing the score. It should also
allow us to skip more conjunction elements, as that requires
the bit being set.
The type refinement context builder had a bunch of logic to try to
model type refinement contexts for the first variable declaration that
shows up within a pattern binding declaration. Instead, model this
more syntactically by creating a type refinement context for the
pattern binding declaration itself. This both addresses a regression
in the handling of `if #available` within a closure that's part of an
initializer, and fixes a bug in the same area where similar code has
explicit availability annotations.
This state is a holdover from when accessors we stored "alongside"
their variable declarations, rather than contained within them. That's
no longer the case, so we don't need to track this information any
more.
Eager expansion of type refinement contexts (TRCs) for variables
within pattern binding declarations is causing cyclic references in
some places involving macros. Make this expansion lazy, triggered by
walking into these pattern binding declarations as part of (e.g.)
availability queries.
Another step toward fixing the cyclic references in rdar://112079160.
Querying property wrappers involves semantic analysis that can cause
cyclic references while building the type refinement context, and it's
unnecessary: we need only know that these are custom attributes to
incorporate their source ranges. Switch to the simpler/cheaper query.
A small part of fixing the cyclic references in rdar://112079160.
Fix an issue uncovered by the stress tester where
the brace element skipping logic could still attempt
to skip a single-expression body of an if/switch
expr.
Skip type-checking multi-statement branches if the
completion is in a single-expression branch, and
skip type-checking the expression as a whole if
the completion is in a multi-statement branch.
Run PreCheckFunctionBodyRequest to ensure we insert
an implicit return for an if/switch if needed, and
ensure we don't try and type-check an element in a
SingleValueStmtExpr separately, as it should be
type-checked as a whole by the constraint system.
This ensures we can propagate a contextual type from
outside an if/switch expression for code completion.
When deriving the `hash(into:)` and `==` witnesses for `Hashable`/`Equatable`
enums, call `_diagnoseUnavailableCodeReached()` in the case bodies for
unavailable enum elements. This is needed because the previously derived code
would operate on the values associated with unavailable enum elements, which is
illegal if the types of those associated values are also unavailable (these
case bodies would have failed typechecking had they been hand-written). The new
structure also more explicitly documents that reaching these cases is
unexpected, since unavailable enum elements should not be instantiated at run
time.
