Skip to content

[Sema] Correct 'await' insertion fixIt #72726

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
May 23, 2024

Conversation

jameesbrown
Copy link
Contributor

@jameesbrown jameesbrown commented Mar 30, 2024

Note this is a duplicate of a previously open pull request I'd closed accidentally: #71716
Resolves #65913

use fixItInsertAfter with the specialized fixIt given it is an implicit DeclRefExpr.

My reasoning is that I saw in ParseStmt.cpp, where we parse a shorthand optional binding we have:

else if (!ThePattern.getPtrOrNull()->getBoundName().empty()) {
    auto bindingName = DeclNameRef(ThePattern.getPtrOrNull()->getBoundName());
    auto loc = DeclNameLoc(ThePattern.getPtrOrNull()->getEndLoc());
    auto declRefExpr = new (Context) UnresolvedDeclRefExpr(bindingName,
                                                           DeclRefKind::Ordinary,
                                                           loc);
    
     declRefExpr->setImplicit();
     Init = makeParserResult(declRefExpr);
```.

@jameesbrown jameesbrown force-pushed the issue-65913 branch 4 times, most recently from ea1b2d0 to 2eda5b7 Compare April 1, 2024 02:22
@AnthonyLatsis
Copy link
Collaborator

@swift-ci please smoke test macOS

@jameesbrown
Copy link
Contributor Author

I see a test failed, but I am a bit confused by the failure.

@AnthonyLatsis
Copy link
Collaborator

The failure is not related.

@jameesbrown jameesbrown force-pushed the issue-65913 branch 2 times, most recently from 0dc03d0 to 4c142e4 Compare April 11, 2024 02:31
@jameesbrown
Copy link
Contributor Author

@AnthonyLatsis @LucianoPAlmeida I've made some updates based off your suggestions. I first tried implementing a traversal through StmtConditionElements by following ArgumentList as an example but somehow free was being called twice on my Walker and I was getting exceptions in my walkToStmtConditionElementPost. I didn't figure that part out but it did lead me to understand the code a bit more. I realized that what was making this more complicated than it should be was that we were walking too far in the case of a shorthand optional binding. What I did was make a small change in walkToAnchor so that we stop if we see an implicit DeclRefExpr. I then cleaned up the code a little by moving the creation of the fixit to its own function.

@LucianoPAlmeida
Copy link
Contributor

@swift-ci Please smoke test

@LucianoPAlmeida
Copy link
Contributor

It seems good to me, but wait for code owners review before merging :)
cc @xedin

@jameesbrown
Copy link
Contributor Author

@xedin When you have some time - Could you take a look at this please?

@xedin
Copy link
Contributor

xedin commented May 18, 2024

Sorry I missed this, will add it to the queue for Monday!

@xedin
Copy link
Contributor

xedin commented May 22, 2024

I didn’t forget about this, will take a look tomorrow!

Copy link
Contributor

@xedin xedin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@xedin
Copy link
Contributor

xedin commented May 22, 2024

@swift-ci please smoke test

Copy link
Collaborator

@AnthonyLatsis AnthonyLatsis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job!

@AnthonyLatsis
Copy link
Collaborator

Please consider tidying up the commit message. NB: I do not recommend including a link to the issue because it spawns permanent commit activity items in the issue every time you force-push, but if you wish to, please place the link in the body rather than the title.

@jameesbrown
Copy link
Contributor Author

@AnthonyLatsis I will do this (tidy up commit message) and I see your point about linking the issue; I'll avoid doing that in the future.

When using shorthand syntax for optional binding,
if the variable we are binding is accessed asynchronously,
provide an insertion fixIt of the form: ' = await (identifier)'.
Previously, we would suggest only adding the 'await'
which resulted in an error since the identifier is required.
@jameesbrown jameesbrown changed the title issue #65913 - Correct wrong insertion point suggestion when using sh… [Sema] Correct 'await' insertion fixIt May 23, 2024
@jameesbrown
Copy link
Contributor Author

@AnthonyLatsis Following the guidelines I cleaned up the commit message, I also have removed some of the not needed test functions you had pointed out. Thank you for all your reviewing! It is much appreciated.

@AnthonyLatsis
Copy link
Collaborator

@swift-ci please smoke test

@AnthonyLatsis AnthonyLatsis enabled auto-merge May 23, 2024 18:39
@AnthonyLatsis AnthonyLatsis merged commit 3ae93a9 into swiftlang:main May 23, 2024
3 checks passed
@jameesbrown jameesbrown deleted the issue-65913 branch May 23, 2024 21:06
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.

Compiler suggests a wrong insertion point for 'await' in if let ....
4 participants