regression: c"..." are experimental

[Mark-Simulacrum]

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?

https://crater-reports.s3.amazonaws.com/beta-1.71-4/beta-2023-06-25/gh/noc7c9.pyfection/log.txt

[fmease]

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) => {}; }

fn main() { 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

@rustbot label S-has-mcve

[fmease]

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).

[hameerabbasi]

Assigning P-medium since this is only a warning, and only valid for older editions of Rust.

@rustbot label -I-prioritize +P-medium

[fmease]

since this is only a warning

@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]

@fmease Do you recommend P-high? Feel free to change the label if so.

[fmease]

I guess the priority is fine, I just wanted to set the record straight :)

[fmease]

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).

@rustbot label -E-needs-bisection

[compiler-errors]

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]

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]

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]

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).

[fmease]

This is now fixed on beta and can be closed, right?

[nagisa]

Correct, we have an issue tracking reimplementation at #113333