Skip to content

[CodeCompletion] Always look into decls to find the parsed expression #28896

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
Jan 14, 2020

Conversation

rintaro
Copy link
Member

@rintaro rintaro commented Dec 20, 2019

In fast completion scenario, AbstractFunctionDecl may have the body from the different file than the decl itself. That may confuses source range checking.

As a workaround, always look into decls regardless of the range. This should not regress the speed of the searching much because statements/expressions (including the nested function bodies) in the decl is still skipped if they are outside the range.

rdar://problem/58098222

In fast completion scenario, 'AbstractFunctionDecl' may have the body
from the different file than the decl itself. Thay may confuses source
range checking.

As a workaround, always look into decls regardless of the range. This
should not regress the speed of the searching much because
statements/expressions (including nested function bodies) in the decl
is still skipped if it's outside the range.

rdar://problem/58098222
@rintaro
Copy link
Member Author

rintaro commented Dec 20, 2019

@swift-ci Please smoke test

1 similar comment
@rintaro
Copy link
Member Author

rintaro commented Dec 20, 2019

@swift-ci Please smoke test

@rintaro
Copy link
Member Author

rintaro commented Dec 20, 2019

@benlangmuir Another solution is to only check the end loc (i.e. !SM.isBeforeInBuffer(Node->getEndLoc, TargetRange.Start)) because, in the case, the end loc points } and it's from the same buffer as the parse expression. However it's just a coincidence, and perhaps we might want to use the brace { ... } locations from the original buffer, for some reasons.
What do you think?

Copy link
Contributor

@benlangmuir benlangmuir left a comment

Choose a reason for hiding this comment

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

LGTM as a workaround

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