Skip to content
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

internal: Don't mutate syntax trees when preparing proc-macro input #10025

Merged
merged 2 commits into from
Aug 28, 2021

Conversation

Veykril
Copy link
Member

@Veykril Veykril commented Aug 25, 2021

Fixes #10013

@@ -512,8 +531,11 @@ impl TokenConvertor for Convertor {
if !&self.range.contains_range(curr.text_range()) {
return None;
}
self.current = curr.next_token();

self.current = match self.censor {
Copy link
Member

Choose a reason for hiding this comment

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

Oh wow, didn't realise that we already use TextRanges here. Ok I guess, but I'd refeactor that away some day -- I don't see a reason for us to rely on raw ranges here :)

Copy link
Member Author

Choose a reason for hiding this comment

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

The if !&self.range.contains_range(curr.text_range()) seems unnecessary in the first place, as we get all tokens from the node that has that range here anyways.

I figured using a TextRange for the censor would be alright given we only want to censor one part in the node so far, which would be simpler to handle than a slice of nodes.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I guess that's ok, although, semantically I'd expect a hash set of nodes, which we can .skip_subtree in Preoreder

Copy link
Member Author

Choose a reason for hiding this comment

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

Looks like that check wasnt pointless, makes sense that the token iteartion leaves the node if its not a root node.

Using preorder sounds nice compared to iterating the tokens via next_token, will adapt that to that instead.

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually using preorder seems non-trivial since we are interested in the tokens in order but that only gives us the nodes. I'll leave this as is for now.

@Veykril Veykril force-pushed the non-mut-exp branch 2 times, most recently from 1323c00 to d50f268 Compare August 25, 2021 17:56
@Veykril Veykril marked this pull request as ready for review August 25, 2021 17:56
@Veykril
Copy link
Member Author

Veykril commented Aug 28, 2021

bors r+

@bors
Copy link
Contributor

bors bot commented Aug 28, 2021

@bors bors bot merged commit fae440c into rust-lang:master Aug 28, 2021
@lnicola lnicola changed the title Don't mutate syntax trees when preparing proc-macro input internal: Don't mutate syntax trees when preparing proc-macro input Aug 28, 2021
@Veykril Veykril deleted the non-mut-exp branch August 28, 2021 15:09
bors bot added a commit that referenced this pull request Sep 19, 2021
10289: fix: Only strip derive attributes when preparing macro input r=Veykril a=Veykril

Fixes #10246
cc rust-analyzer/rowan#114, follow up to #10025

Co-authored-by: Lukas Wirth <[email protected]>
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.

Consider not mutating syntax tree when preparing inpus for attr/derive proc macros
2 participants