Fix const items not being allowed to be called r#move or r#static
#137140
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
|
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. |
jieyouxu
reviewed
Feb 16, 2025
This comment was marked as resolved.
This comment was marked as resolved.
jieyouxu
added
A-parser
|
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. |
Noratrieb
added
S-waiting-on-author
Noratrieb
force-pushed
the
const-move
branch
from
d4d2941 to
c03b67a
Compare
compiler-errors
approved these changes
Feb 16, 2025
Noratrieb
added
S-waiting-on-review
|
@theemathas pointed out that i wrote this test in a quite silly way, so I fixed that. And I added revisions. |
jieyouxu
requested changes
Feb 16, 2025
rustbot
added
S-waiting-on-author
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.
Noratrieb
force-pushed
the
const-move
branch
from
c03b67a to
8a02724
Compare
Noratrieb
added
S-waiting-on-review
jieyouxu
approved these changes
Feb 16, 2025
|
@bors r=jieyouxu,compiler-errors |
bors
added
S-waiting-on-bors
jieyouxu
removed
the
T-lang
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Feb 16, 2025
…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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 17, 2025
…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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 17, 2025
…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
traviscross
approved these changes
Feb 17, 2025
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 17, 2025
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Because of an ambiguity with const closures, the parser needs to ensure that for a const item, the
constkeyword isn't followed by amoveorstatickeyword, as that would indicate a const closure:This check did not take raw identifiers into account, therefore being unable to distinguish between
const moveandconst 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