You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not clear to me whether this is expected -- I don't see much in the way of commentary on the RFC, and I thought we had reserved these literals previously, but perhaps that reservation was incomplete?
c"…" inside macro calls (with macro matches like c$e:expr) should definitely continue to compile in editions 2015 and 2018. Those prefixes are only reserved in edition 2021 and onward.
The following reproducer compiles successfully on stable in editions 2015 and 2018 but fails to compile on beta and nightly while it should remain valid:
macro_rules! m {(c$e:expr) => {};}fnmain(){m!(c"hello");}
stderr
error: no rules expected the token `c"hello"`
--> src/main.rs:3:16
|
1 | macro_rules! m { (c$e:expr) => {}; }
| -------------- when calling this macro
2 |
3 | fn main() { m!(c"hello"); }
| ^^^^^^^^ no rules expected this token in macro call
|
note: while trying to match `c`
--> src/main.rs:1:19
|
1 | macro_rules! m { (c$e:expr) => {}; }
| ^
error[E0658]: `c".."` literals are experimental
--> src/main.rs:3:16
|
3 | fn main() { m!(c"hello"); }
| ^^^^^^^^
|
= note: see issue #105723 <https://github.com/rust-lang/rust/issues/105723> for more information
This would be easy to fix if we had access to the edition in rustc_lexer but I don't know if it's acceptable to pass that information to Cursor.
Alternatively, we could unravel CStr and CStrRaw literals into two tokens (Ident and Str / StrRaw) after the fact in rustc_parse::lexer where we have access to the edition, although that's a bit messier I guess (and other parsers like rust-analyzer's would need to remember this step & redo this work).
Without doing a bisection, I can tell you that this regressed in #108801 (regressed in: 8ff3903, still a regression after refactoring commit: a49570f) when rustc_lexer/src/lib.rs was modified (manually reverting those changes to the lexer makes the reproducer compile again).
Let's at least revert the lexer changes until @fee1-dead or someone else can fix this in a way that's compatible with the pre-2021 editions @fmease, do you want to do that, or shall I?
Just reverting the lexer change & keeping everything else related to c_str_literals? I can do that within this hour when I find the time. Edit: And reverting all the tests.
To be clear, all the existing cstring tests would break, so you'll have to mark some of the tests as // known-bug: ### and open an issue tracking that functionality getting added. That'll make it so someone knows to pick it up and fix it 😸
Activity
fmease commentedon Jul 1, 2023
c"…"inside macro calls (with macro matches likec$e:expr) should definitely continue to compile in editions 2015 and 2018. Those prefixes are only reserved in edition 2021 and onward.The following reproducer compiles successfully on stable in editions 2015 and 2018 but fails to compile on beta and nightly while it should remain valid:
stderr
@rustbot label S-has-mcve
fmease commentedon Jul 1, 2023
This would be easy to fix if we had access to the edition in
rustc_lexerbut I don't know if it's acceptable to pass that information toCursor.Alternatively, we could unravel
CStrandCStrRawliterals into two tokens (IdentandStr/StrRaw) after the fact inrustc_parse::lexerwhere we have access to the edition, although that's a bit messier I guess (and other parsers like rust-analyzer's would need to remember this step & redo this work).hameerabbasi commentedon Jul 2, 2023
Assigning P-medium since this is only a warning, and only valid for older editions of Rust.
@rustbot label -I-prioritize +P-medium
fmease commentedon Jul 2, 2023
@hameerabbasi It's not a warning but a hard error. noc7c9/pyfection no longer compiles due to this bug. rustc lexes the crate differently than before.
hameerabbasi commentedon Jul 2, 2023
@fmease Do you recommend
P-high? Feel free to change the label if so.1 remaining item
fmease commentedon Jul 2, 2023
Without doing a bisection, I can tell you that this regressed in #108801 (regressed in: 8ff3903, still a regression after refactoring commit: a49570f) when
rustc_lexer/src/lib.rswas modified (manually reverting those changes to the lexer makes the reproducer compile again).@rustbot label -E-needs-bisection
compiler-errors commentedon Jul 4, 2023
Let's at least revert the lexer changes until @fee1-dead or someone else can fix this in a way that's compatible with the pre-2021 editions @fmease, do you want to do that, or shall I?
fmease commentedon Jul 4, 2023
Just reverting the lexer change & keeping everything else related to
c_str_literals? I can do that within this hour when I find the time. Edit: And reverting all the tests.@rustbot claim
compiler-errors commentedon Jul 4, 2023
To be clear, all the existing cstring tests would break, so you'll have to mark some of the tests as
// known-bug: ###and open an issue tracking that functionality getting added. That'll make it so someone knows to pick it up and fix it 😸fmease commentedon Jul 4, 2023
Slightly unrelated, but I've noticed that the GitHub label should be renamed from F-c_str_literal to F-c_str_literals and its description needs to be updated, too (see https://github.com/rust-lang/rust/blob/master/compiler/rustc_feature/src/active.rs for the source of truth).
Rollup merge of rust-lang#113334 - fmease:revert-lexing-c-str-lits, r…
fmease commentedon Jul 12, 2023
This is now fixed on beta and can be closed, right?
nagisa commentedon Jul 16, 2023
Correct, we have an issue tracking reimplementation at #113333