-
Couldn't load subscription status.
- Fork 13.9k
Less NoDelim
#96421
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
Less NoDelim
#96421
Conversation
|
Some changes occurred in src/tools/rustfmt. cc @rust-lang/rustfmt |
|
@petrochenkov: see what you think of this. I was trying to understand |
This comment has been minimized.
This comment has been minimized.
73f9af9 to
7c32842
Compare
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.
Is this still necessary?
There's no longer a DelimToken::NoDelim at the top level.
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.
There's also a similar // HACK comment lower in the same function.
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.
The "mismatched None delimiter at the top level" here refers to token, which comes from the iterator, not the frame. Indeed, the condition looks for a non-NoDelim in the frame. So this change preserves the existing behaviour, as I understand it.
More generally: there are three HACK comments in this function, and a comment at the top of the function referring to #67062. The HACK comments are on three if statements. I tried changing the bodies of those three if statements to panic!() and the test suite passed. I then tried removing all three if statements and the test suite again passed.
These if statements were added in #82608, with an explanation here. I don't know if (a) they never did anything useful, (b) they do something useful but we have no test coverage for them, or (c) something has changed in the meantime that means they are no longer necessary.
I suggest we leave this change as is, and consider removing these hacks in a separate PR. That way if there are any regressions they'll be easier to deal with.
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.
I have filed #96543 to remove the hacks.
The code currently ignores the actual delimiter on the RHS and fakes up a `NoDelim`/`DelimSpan::dummy()` one. This commit changes it to use the actual delimiter. The commit also reorders the fields for the `Delimited` variant to match the `Sequence` variant.
7c32842 to
86f0117
Compare
|
I have addresses the comments, except for those explained above. |
|
@bors r+ |
|
📌 Commit 86f0117 has been approved by |
…enkov Less `NoDelim` Currently there are several places where `NoDelim` (which really means "implicit delimiter" or "invisible delimiter") is used to mean "no delimiter". The name `NoDelim` is a bit misleading, and may be a cause. This PR changes these places, e.g. by changing a `DelimToken` to `Option<DelimToken>` and then using `None` to mean "no delimiter". As a result, the *only* place where `NoDelim` values are now produced is within: - `Delimiter::to_internal()`, when converting from `Delimiter::None`. - `FlattenNonterminals::process_token()`, when converting `TokenKind::Interpolated`. r? `@petrochenkov`
…enkov Less `NoDelim` Currently there are several places where `NoDelim` (which really means "implicit delimiter" or "invisible delimiter") is used to mean "no delimiter". The name `NoDelim` is a bit misleading, and may be a cause. This PR changes these places, e.g. by changing a `DelimToken` to `Option<DelimToken>` and then using `None` to mean "no delimiter". As a result, the *only* place where `NoDelim` values are now produced is within: - `Delimiter::to_internal()`, when converting from `Delimiter::None`. - `FlattenNonterminals::process_token()`, when converting `TokenKind::Interpolated`. r? ``@petrochenkov``
…enkov Less `NoDelim` Currently there are several places where `NoDelim` (which really means "implicit delimiter" or "invisible delimiter") is used to mean "no delimiter". The name `NoDelim` is a bit misleading, and may be a cause. This PR changes these places, e.g. by changing a `DelimToken` to `Option<DelimToken>` and then using `None` to mean "no delimiter". As a result, the *only* place where `NoDelim` values are now produced is within: - `Delimiter::to_internal()`, when converting from `Delimiter::None`. - `FlattenNonterminals::process_token()`, when converting `TokenKind::Interpolated`. r? ```@petrochenkov```
Rollup of 7 pull requests Successful merges: - rust-lang#96377 (make `fn() -> _ { .. }` suggestion MachineApplicable) - rust-lang#96397 (Make EncodeWide implement FusedIterator) - rust-lang#96421 (Less `NoDelim`) - rust-lang#96432 (not need `Option` for `dbg_scope`) - rust-lang#96466 (Better error messages when collecting into `[T; n]`) - rust-lang#96471 (replace let else with `?`) - rust-lang#96483 (Add missing `target_feature` to the list of well known cfg names) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
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`
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``
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/rust#96421 r? ``@nnethercote``
Currently there are several places where
NoDelim(which really means "implicit delimiter" or "invisible delimiter") is used to mean "no delimiter". The nameNoDelimis a bit misleading, and may be a cause.This PR changes these places, e.g. by changing a
DelimTokentoOption<DelimToken>and then usingNoneto mean "no delimiter". As a result, the only place whereNoDelimvalues are now produced is within:Delimiter::to_internal(), when converting fromDelimiter::None.FlattenNonterminals::process_token(), when convertingTokenKind::Interpolated.r? @petrochenkov