Skip to content

[CS] Better handle paren fix-its for unresolved chains #38748

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 4, 2021

Conversation

hamishknight
Copy link
Contributor

I missed this case when implementing #38631. 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

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
@hamishknight
Copy link
Contributor Author

@swift-ci please test

@hamishknight hamishknight requested a review from xedin August 4, 2021 13:36
@hamishknight hamishknight merged commit caae8d6 into swiftlang:main Aug 4, 2021
@hamishknight hamishknight deleted the a-better-precedent branch August 4, 2021 18:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants