-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
rustc_ast: Harmonize delimiter naming with proc_macro::Delimiter
#96433
Conversation
Some changes occurred in src/tools/rustfmt. cc @rust-lang/rustfmt Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
This comment has been minimized.
This comment has been minimized.
token::OpenDelim(Delimiter::Brace) => "{".into(), | ||
token::CloseDelim(Delimiter::Brace) => "}".into(), | ||
token::OpenDelim(Delimiter::Invisible) | token::CloseDelim(Delimiter::Invisible) => { | ||
"".into() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Off-topic: I was thinking about rendering these as something like /*⟪*/
and /*⟫*/
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, but I think it would require #96421 to land, to avoid printing this in #[word]
and #[key = "value"]
attributes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me with the comment below addressed.
@bors delegate+
I'm now also wondering if "implicit" is better than "invisible", mostly because I just read https://github.com/rust-lang/reference/blob/master/src/procedural-macros.md which uses "implicit". But then, I see that https://docs.rs/syn/latest/syn/ uses "invisible". I'll let you decide :) |
I think the |
📌 Commit ce00327784d2dcfbc1db6478a555ee8c69c4c8b4 has been approved by |
This comment was marked as resolved.
This comment was marked as resolved.
@bors r=nnethercote |
📌 Commit 2733ec1 has been approved by |
rustc_ast: Harmonize delimiter naming with `proc_macro::Delimiter` Compiler cannot reuse `proc_macro::Delimiter` directly due to extra impls, but can at least use the same naming. After this PR the only difference between these two enums is that `proc_macro::Delimiter::None` is turned into `token::Delimiter::Invisible`. It's my mistake that the invisible delimiter is called `None` on stable, during the stabilization I audited the naming and wrote the docs, but missed the fact that the `None` naming gives a wrong and confusing impression about what this thing is. cc rust-lang#96421 r? `@nnethercote`
Rollup of 5 pull requests Successful merges: - rust-lang#95312 (Ensure that `'_` and GAT yields errors) - rust-lang#96405 (Migrate ambiguous plus diagnostic to the new derive macro) - rust-lang#96409 (Recover suggestions to introduce named lifetime under NLL) - rust-lang#96433 (rustc_ast: Harmonize delimiter naming with `proc_macro::Delimiter`) - rust-lang#96480 (Fixed grammatical error in example comment) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Compiler cannot reuse
proc_macro::Delimiter
directly due to extra impls, but can at least use the same naming.After this PR the only difference between these two enums is that
proc_macro::Delimiter::None
is turned intotoken::Delimiter::Invisible
.It's my mistake that the invisible delimiter is called
None
on stable, during the stabilization I audited the naming and wrote the docs, but missed the fact that theNone
naming gives a wrong and confusing impression about what this thing is.cc #96421
r? @nnethercote