expected unsuffixed literal or identifier, found IN_ISDIR
#122796
Labels
A-attributes
Area: Attributes (`#[…]`, `#![…]`)
C-discussion
Category: Discussion or questions that doesn't represent real issues.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
rustbot
added
the
needs-triage
|
The code works with nightly-2024-03-16: |
fmease
added
A-attributes
|
Exhibit A: #![crate_type = "lib"]
#![allow(dead_code)]
pub const IN_ISDIR: usize = 0;
macro_rules! m {
($bit: ident) => {
#[doc(alias = $bit)]
pub const fn foo() {}
};
}
struct Bar;
impl Bar {
m!(IN_ISDIR);
}OK on stable, ERROR on nightly 2024-03-19. Exhibit B: #![crate_type = "lib"]
#![allow(dead_code)]
pub const IN_ISDIR: usize = 0;
macro_rules! m {
($bit: ident) => {
#[doc(alias = $bit)]
pub const fn foo() {}
};
}
struct Bar;
m!(IN_ISDIR);ERROR on both. Exhibit C: #![crate_type = "lib"]
#![allow(dead_code)]
pub const IN_ISDIR: usize = 0;
macro_rules! m {
($bit: ident) => {
#[doc(alias = $bit)]
pub fn foo() {} // <- notice not `const` like Exhibit A
};
}
struct Bar;
impl Bar {
m!(IN_ISDIR);
}ERROR on both. |
|
First and foremost, sorry for breaking your crate! However this was an intentional breaking change. We used to not validate attributes on certain kinds of associated functions. We did a crater run and found only a single regression. Therefore I decided to roll with it. |
|
Intentionally regressed in #121545. |
|
Makes a lot of sense, was about to say the stable behavior is the surprising one lol |
|
@Thomasdezeeuw Your |
If this is an intentional regression, we can probably close this issue? |
|
The diagnostic isn't great tho lol, we should open an issue if there isn't one already. We are not expecting an identifier. |
Feel free to create an issue for the diagnostic (which is actionable) |
I will look into that later. |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
May 10, 2024
…m, r=nnethercote Fix parse error message for meta items Addresses rust-lang#122796 (comment), cc [`@]Thomasdezeeuw.` For attrs inside of a macro like `#[doc(alias = $ident)]` or `#[cfg(feature = $ident)]` where `$ident` is a macro metavariable of fragment kind `ident`, we used to say the following when expanded (with `$ident` ⟼ `ident`): ``` error: expected unsuffixed literal or identifier, found `ident` --> weird.rs:6:19 | 6 | #[cfg(feature = $ident)] | ^^^^^^ ... 11 | m!(id); | ------ in this macro invocation | = note: this error originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info) ``` This was incorrect and caused confusion, justifiably so (see rust-lang#122796). In this position, we only accept/expect *unsuffixed literals* which consist of numeric & string literals as well as the boolean literals / the keywords / the reserved identifiers `false` & `true` **but not** arbitrary identifiers. Furthermore, we used to suggest garbage when encountering unexpected non-identifier tokens: ``` error: expected unsuffixed literal, found `-` --> weird.rs:16:17 | 16 | #[cfg(feature = -1)] | ^ | help: surround the identifier with quotation marks to parse it as a string | 16 | #[cfg(feature =" "-1)] | + + ``` Now we no longer do.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
May 10, 2024
…m, r=nnethercote Fix parse error message for meta items Addresses rust-lang#122796 (comment), cc [``@]Thomasdezeeuw.`` For attrs inside of a macro like `#[doc(alias = $ident)]` or `#[cfg(feature = $ident)]` where `$ident` is a macro metavariable of fragment kind `ident`, we used to say the following when expanded (with `$ident` ⟼ `ident`): ``` error: expected unsuffixed literal or identifier, found `ident` --> weird.rs:6:19 | 6 | #[cfg(feature = $ident)] | ^^^^^^ ... 11 | m!(id); | ------ in this macro invocation | = note: this error originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info) ``` This was incorrect and caused confusion, justifiably so (see rust-lang#122796). In this position, we only accept/expect *unsuffixed literals* which consist of numeric & string literals as well as the boolean literals / the keywords / the reserved identifiers `false` & `true` **but not** arbitrary identifiers. Furthermore, we used to suggest garbage when encountering unexpected non-identifier tokens: ``` error: expected unsuffixed literal, found `-` --> weird.rs:16:17 | 16 | #[cfg(feature = -1)] | ^ | help: surround the identifier with quotation marks to parse it as a string | 16 | #[cfg(feature =" "-1)] | + + ``` Now we no longer do.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
May 10, 2024
Rollup merge of rust-lang#124778 - fmease:fix-diag-msg-parse-meta-item, r=nnethercote Fix parse error message for meta items Addresses rust-lang#122796 (comment), cc [``@]Thomasdezeeuw.`` For attrs inside of a macro like `#[doc(alias = $ident)]` or `#[cfg(feature = $ident)]` where `$ident` is a macro metavariable of fragment kind `ident`, we used to say the following when expanded (with `$ident` ⟼ `ident`): ``` error: expected unsuffixed literal or identifier, found `ident` --> weird.rs:6:19 | 6 | #[cfg(feature = $ident)] | ^^^^^^ ... 11 | m!(id); | ------ in this macro invocation | = note: this error originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info) ``` This was incorrect and caused confusion, justifiably so (see rust-lang#122796). In this position, we only accept/expect *unsuffixed literals* which consist of numeric & string literals as well as the boolean literals / the keywords / the reserved identifiers `false` & `true` **but not** arbitrary identifiers. Furthermore, we used to suggest garbage when encountering unexpected non-identifier tokens: ``` error: expected unsuffixed literal, found `-` --> weird.rs:16:17 | 16 | #[cfg(feature = -1)] | ^ | help: surround the identifier with quotation marks to parse it as a string | 16 | #[cfg(feature =" "-1)] | + + ``` Now we no longer do.
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
May 11, 2024
…hercote Fix parse error message for meta items Addresses rust-lang/rust#122796 (comment), cc [``@]Thomasdezeeuw.`` For attrs inside of a macro like `#[doc(alias = $ident)]` or `#[cfg(feature = $ident)]` where `$ident` is a macro metavariable of fragment kind `ident`, we used to say the following when expanded (with `$ident` ⟼ `ident`): ``` error: expected unsuffixed literal or identifier, found `ident` --> weird.rs:6:19 | 6 | #[cfg(feature = $ident)] | ^^^^^^ ... 11 | m!(id); | ------ in this macro invocation | = note: this error originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info) ``` This was incorrect and caused confusion, justifiably so (see #122796). In this position, we only accept/expect *unsuffixed literals* which consist of numeric & string literals as well as the boolean literals / the keywords / the reserved identifiers `false` & `true` **but not** arbitrary identifiers. Furthermore, we used to suggest garbage when encountering unexpected non-identifier tokens: ``` error: expected unsuffixed literal, found `-` --> weird.rs:16:17 | 16 | #[cfg(feature = -1)] | ^ | help: surround the identifier with quotation marks to parse it as a string | 16 | #[cfg(feature =" "-1)] | + + ``` Now we no longer do.
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this issue
May 24, 2024
…hercote Fix parse error message for meta items Addresses rust-lang/rust#122796 (comment), cc [``@]Thomasdezeeuw.`` For attrs inside of a macro like `#[doc(alias = $ident)]` or `#[cfg(feature = $ident)]` where `$ident` is a macro metavariable of fragment kind `ident`, we used to say the following when expanded (with `$ident` ⟼ `ident`): ``` error: expected unsuffixed literal or identifier, found `ident` --> weird.rs:6:19 | 6 | #[cfg(feature = $ident)] | ^^^^^^ ... 11 | m!(id); | ------ in this macro invocation | = note: this error originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info) ``` This was incorrect and caused confusion, justifiably so (see #122796). In this position, we only accept/expect *unsuffixed literals* which consist of numeric & string literals as well as the boolean literals / the keywords / the reserved identifiers `false` & `true` **but not** arbitrary identifiers. Furthermore, we used to suggest garbage when encountering unexpected non-identifier tokens: ``` error: expected unsuffixed literal, found `-` --> weird.rs:16:17 | 16 | #[cfg(feature = -1)] | ^ | help: surround the identifier with quotation marks to parse it as a string | 16 | #[cfg(feature =" "-1)] | + + ``` Now we no longer do.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have the following (open source) code: https://github.com/Thomasdezeeuw/heph/blob/1c7ee4af37627fcfb11749389973fa5e4a34a0bf/rt/src/fs/watch.rs#L354-L466. It's over a 100 lines and I'm not sure what is causing the issue.
This compiled fine since it was added to the repository, latest nightly compiler that is know to work is
from rustc 1.78.0-nightly (c67326b06 2024-03-15).However using the currently nightly compiler,
1.79.0-nightly (a7e4de13c 2024-03-19), fails to compile it giving the following errors:Also available on the CI:
There are two problems. First, the regression from the previous nightly. Second, the error message is rather confusing, I have would have no idea what the actual problem is.
Meta
rustc --version --verbose:The text was updated successfully, but these errors were encountered: