[CodeComplete] A couple of contextual type handling tweaks #71211
Conversation
hamishknight
requested review from
ahoppen,
bnbarham and
rintaro
as code owners
hamishknight
force-pushed
the
completion-tweaks
branch
from
b93d143 to
5378f3a
Compare
If we know we have a Void expected type, don't set `ExpectsNonVoid` to `true`.
This can occur for e.g multi-statement closure returns (and soon for singe-expression closures too), so fall back to evaluating the expression type if it's not fully resolved.
hamishknight
force-pushed
the
completion-tweaks
branch
from
5378f3a to
d022cf8
Compare
|
@swift-ci please test |
| return self.#^TestExplicitSingleExprClosureBinding^# | ||
| } | ||
| } | ||
| // FIXME: Because we have an explicit return, and no expected type, we shouldn't suggest Void. |
There was a problem hiding this comment.
Actually, I think suggesting values that return Void after return makes sense if the closure has a Void return type. For example return callback() is a common pattern for early returns out of closures and as a shorthand of callback(); return
So, I would just remove the FIXME
There was a problem hiding this comment.
Right, but in this case there's no contextual type. If there was an explicit Void contextual type, we'd allow it
There was a problem hiding this comment.
We could carve out an exception for CTP_ReturnStmt if we really wanted this behavior though
There was a problem hiding this comment.
I think what I’m trying to say is that I don’t really care about this case because you can argue either way and I would just remove the FIXME. But if you want to keep it, that’s good with me as well.
There was a problem hiding this comment.
Going to keep it for now since this is going to change anyway with my constraint system patch. I should also note that not suggesting Void is also the behavior we currently have for multi-statement closure returns. I don't really feel too strongly about it either way (and am happy to carve out an exception for returns if we want that), but I think we should at least be consistent there
There was a problem hiding this comment.
Changing in #71272
Found while cleaning up the constraint system's handling of ReturnStmts, improve the handling of contextual types in a couple of cases.