[CS] Allow contextual types with errors #84003
Conversation
If we have a hole binding for the result of a closure, avoid
introducing Void as an additional binding since that'll just cause
local solution ambiguities. This doesn't affect regular type-checking
since we end up treating such ambiguities as "identical", so we just
pick one. But for completion, we don't do such filtering so need to
make sure we end up with the hole solution to avoid treating Void as
the contextual type for cases such as:
```
_ = {
x.#^CC^#
}
```
Currently we avoid this by not handling holes in `repairFailures`
for closure body locators, but I'm changing that in the next commit.
Eagerly bind invalid type references to holes and propagate contextual type holes in `repairFailures`. This avoids some unnecessary diagnostics in cases where we have an invalid contextual type.
Previously we would skip type-checking the result expression of a `return` or the initialization expression of a binding if the contextual type had an error, but that misses out on useful diagnostics and prevents code completion and cursor info from working. Change the logic such that we open ErrorTypes as holes and continue to type-check.
hamishknight
requested review from
CodaFi,
DougGregor,
bnbarham,
hborla,
rintaro,
slavapestov and
xedin
as code owners
|
@swift-ci please test |
|
@swift-ci please SourceKit stress test |
xedin
left a comment
xedin
left a comment
There was a problem hiding this comment.
Looks good to me! I left a few comments inline about use of the temporary type variables.
| // become holes. | ||
| auto *tv = CS.createTypeVariable(CS.getConstraintLocator(repr), | ||
| TVO_CanBindToHole); | ||
| CS.recordTypeVariablesAsHoles(tv); |
There was a problem hiding this comment.
TypeRepr is an originator for a placeholder type, could we avoid allocating a type variable here?
There was a problem hiding this comment.
Hmm yeah, let me look into that in a follow-up
| // For ErrorTypes we want to eagerly bind to a hole since we | ||
| // know this is where the issue is. | ||
| if (isa<ErrorType>(type.getPointer())) { | ||
| recordTypeVariablesAsHoles(tv); |
There was a problem hiding this comment.
It's nice that placeholder type could capture a type variable with its location but I'm wondering whether we use that information or maybe we should just let ErrorType be an originator for a placeholder and avoid having to allocate additional type variables here to immediately bind them?...
|
@swift-ci please smoke test macOS |
2 participants
Previously we would skip type-checking the result expression of a
returnor the initialization expression of a binding if the contextual type had an error, but that misses out on useful diagnostics and prevents code completion and cursor info from working. Change the logic such that we open ErrorTypes as holes and continue to type-check.