Skip to content

[incrParse] Fix SyntaxParsingCache::translateToPreEditPosition() #20321

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
Nov 6, 2018

Conversation

rintaro
Copy link
Member

@rintaro rintaro commented Nov 5, 2018

If the position is in the region that is inserted by the edits, "pre-edit" position shouldn't exist. So we cannot reuse the node at the position.

rdar://problem/45259469
https://bugs.swift.org/browse/SR-8995

CC: @ahoppen

@rintaro rintaro requested review from nkcsgexi and nathawes November 5, 2018 06:39
@rintaro
Copy link
Member Author

rintaro commented Nov 5, 2018

@swift-ci Please smoke test


// SR-8995 rdar://problem/45259469

self = <<STRING<|||_ _>>>foo(1)[object1, object2] + o bar(1)
Copy link
Member Author

@rintaro rintaro Nov 5, 2018

Choose a reason for hiding this comment

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

In this test case, the second _ inserted used to be translated to the "pre-edit" position of bar(1). So the parser tried to reuse bar(1) when parsing _foo(1)...

Copy link
Member

@ahoppen ahoppen left a comment

Choose a reason for hiding this comment

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

Thanks for tackling this. I didn't think about it and the testing is definitely way better with the helper function. Some minor comments inline.

static size_t
translateToPreEditPosition(size_t PostEditPosition,
llvm::SmallVector<SourceEdit, 4> Edits);
static bool translateToPreEditPosition(size_t &Position,
Copy link
Member

Choose a reason for hiding this comment

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

I think returning an llvm::Optional<size_t> would be cleaner.

/// specified edits.
/// specified edits. Returns \c true if pre-edit position cannot be
/// determined (for example, the position is in a region which is inserted by
/// a edit).
Copy link
Member

Choose a reason for hiding this comment

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

Nitpick: an edit

Copy link
Member

Choose a reason for hiding this comment

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

While looking through the PR, it somehow took me fairly long to understand when false is returned. I think it might help, if you add something along the lines of returns \c true if no pre-edit position exists because the post-edit position has been inserted by an en edit. It's up to you to decide though. I understand it now.

// Remaining edits doesn't affect the position. (Edits are sorted)
break;
if (Edit.Start + Edit.ReplacementLength > Position)
// This is a position inserted by the edit.
Copy link
Member

Choose a reason for hiding this comment

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

For more clarity, I'd add and thus doesn't exist in the pre-edit version of the file.

If the position is in the region that is inserted by the edits,
'pre-edit' position shouldn't exist. So we cannot reuse the node at the
position.

rdar://problem/45259469
https://bugs.swift.org/browse/SR-8995
@rintaro rintaro force-pushed the incrparse-rdar45259469 branch from f2162b4 to 1f563b3 Compare November 5, 2018 15:27
@rintaro
Copy link
Member Author

rintaro commented Nov 5, 2018

@ahoppen Thanks! updated the PR.

@rintaro
Copy link
Member Author

rintaro commented Nov 5, 2018

@swift-ci Please smoke test

1 similar comment
@rintaro
Copy link
Member Author

rintaro commented Nov 5, 2018

@swift-ci Please smoke test

@rintaro rintaro merged commit c18e735 into swiftlang:master Nov 6, 2018
@rintaro rintaro deleted the incrparse-rdar45259469 branch November 6, 2018 01:25
@nkcsgexi
Copy link
Contributor

nkcsgexi commented Nov 7, 2018

Awesome! @rintaro , could we cherry-pick it to swift-5.0-branch as well?

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.

4 participants