-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Fix const items not being allowed to be called r#move
or r#static
#137140
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
I don't really know if this is something that should get a lang FCP or not... This is definitely a bug and an (older) regression, so I'm inclined to say no. I don't think a lang FCP would be useful, as it's obvious that this should be allowed. But I'll @rust-lang/lang for visibility. |
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 parser change looks good to me, I have a nit about the test.
This comment was marked as resolved.
This comment was marked as resolved.
I'm going to un-nominate this, because I don't think this is worth T-lang's very limited bandwidth. If anyone has objections, you can send them here, but I cannot imagine what an objection would look like :D. |
d4d2941
to
c03b67a
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.
Yeah, this definitely does not need lang discussion because it's just a parser bug.
@theemathas pointed out that i wrote this test in a quite silly way, so I fixed that. And I added revisions. |
Because of an ambiguity with const closures, the parser needs to ensure that for a const item, the `const` keyword isn't followed by a `move` or `static` keyword, as that would indicate a const closure: ```rust fn main() { const move // ... } ``` This check did not take raw identifiers into account, therefore being unable to distinguish between `const move` and `const r#move`. The latter is obviously not a const closure, so it should be allowed as a const item. This fixes the check in the parser to only treat `const ...` as a const closure if it's followed by the *proper keyword*, and not a raw identifier. Additionally, this adds a large test that tests for all raw identifiers in all kinds of positions, including `const`, to prevent issues like this one from occurring again.
c03b67a
to
8a02724
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.
Thanks, also r=me once PR CI is green.
@bors r=jieyouxu,compiler-errors |
…ompiler-errors Fix const items not being allowed to be called `r#move` or `r#static` Because of an ambiguity with const closures, the parser needs to ensure that for a const item, the `const` keyword isn't followed by a `move` or `static` keyword, as that would indicate a const closure: ```rust fn main() { const move // ... } ``` This check did not take raw identifiers into account, therefore being unable to distinguish between `const move` and `const r#move`. The latter is obviously not a const closure, so it should be allowed as a const item. This fixes the check in the parser to only treat `const ...` as a const closure if it's followed by the *proper keyword*, and not a raw identifier. Additionally, this adds a large test that tests for all raw identifiers in all kinds of positions, including `const`, to prevent issues like this one from occurring again. fixes rust-lang#137128
…kingjubilee Rollup of 12 pull requests Successful merges: - rust-lang#136671 (Overhaul `rustc_middle::limits`) - rust-lang#136817 (Pattern Migration 2024: clean up and comment) - rust-lang#136844 (Use `const_error!` when possible) - rust-lang#136953 (rustc_target: import TargetMetadata) - rust-lang#137095 (Replace some u64 hashes with Hash64) - rust-lang#137100 (HIR analysis: Remove unnecessary abstraction over list of clauses) - rust-lang#137105 (Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.) - rust-lang#137120 (Enable `relative-path-include-bytes-132203` rustdoc-ui test on Windows) - rust-lang#137125 (Re-add missing empty lines in the releases notes) - rust-lang#137140 (Fix const items not being allowed to be called `r#move` or `r#static`) - rust-lang#137145 (use add-core-stubs / minicore for a few more tests) - rust-lang#137149 (Remove SSE ABI from i586-pc-windows-msvc) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#136466 (Start removing `rustc_middle::hir::map::Map`) - rust-lang#136671 (Overhaul `rustc_middle::limits`) - rust-lang#136817 (Pattern Migration 2024: clean up and comment) - rust-lang#136844 (Use `const_error!` when possible) - rust-lang#137080 (bootstrap: add more tracing to compiler/std/llvm flows) - rust-lang#137101 (`invalid_from_utf8[_unchecked]`: also lint inherent methods) - rust-lang#137140 (Fix const items not being allowed to be called `r#move` or `r#static`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#137140 - Noratrieb:const-move, r=jieyouxu,compiler-errors Fix const items not being allowed to be called `r#move` or `r#static` Because of an ambiguity with const closures, the parser needs to ensure that for a const item, the `const` keyword isn't followed by a `move` or `static` keyword, as that would indicate a const closure: ```rust fn main() { const move // ... } ``` This check did not take raw identifiers into account, therefore being unable to distinguish between `const move` and `const r#move`. The latter is obviously not a const closure, so it should be allowed as a const item. This fixes the check in the parser to only treat `const ...` as a const closure if it's followed by the *proper keyword*, and not a raw identifier. Additionally, this adds a large test that tests for all raw identifiers in all kinds of positions, including `const`, to prevent issues like this one from occurring again. fixes rust-lang#137128
Because of an ambiguity with const closures, the parser needs to ensure that for a const item, the
const
keyword isn't followed by amove
orstatic
keyword, as that would indicate a const closure:This check did not take raw identifiers into account, therefore being unable to distinguish between
const move
andconst r#move
. The latter is obviously not a const closure, so it should be allowed as a const item.This fixes the check in the parser to only treat
const ...
as a const closure if it's followed by the proper keyword, and not a raw identifier.Additionally, this adds a large test that tests for all raw identifiers in all kinds of positions, including
const
, to prevent issues like this one from occurring again.fixes #137128