Skip to content

Conversation

SparrowLii
Copy link
Member

@SparrowLii SparrowLii commented Sep 1, 2022

Some work of #48685
mk_attr_id uses the AtomicU32 type and will always generate an unique AttrId that different from ones in generated ast, which is inefficient and meaningless in decoding.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 1, 2022
@rust-highfive
Copy link
Contributor

r? @jackh726

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 1, 2022
@cjgillot
Copy link
Contributor

cjgillot commented Sep 1, 2022

Could you elaborate why we don't need the uniqueness of the decoded AttrId?

@bors
Copy link
Collaborator

bors commented Sep 1, 2022

☔ The latest upstream changes (presumably #98960) made this pull request unmergeable. Please resolve the merge conflicts.

@SparrowLii
Copy link
Member Author

Thanks for the reply. I re-examined the usage scenario of the decoder. It is integrated with the generated ast, so it makes sense to generate a unique AttrId. I think this PR can be closed.

@SparrowLii SparrowLii closed this Sep 2, 2022
@SparrowLii SparrowLii deleted the attr_id branch September 2, 2022 01:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants