regression: failed to parse proc-macro input

[Mark-Simulacrum]

cc @dtolnay -- possibly related to syn?

root is termfest, cc @agatan

• agatan/squeeze-rs: start v. end; cc @agatan

[dtolnay]

This is due to 1.36 passing literals in macro input differently than previous releases, and the repo in the crater report pinning an old version of syn (September 2016) that does not parse the new syntax.

[dtolnay]

Minimized:

#!/bin/bash

cargo new repro

echo >>repro/Cargo.toml '
[lib]
proc-macro = true
'

echo >repro/src/lib.rs '
extern crate proc_macro;
use proc_macro::TokenStream;

#[proc_macro_derive(D)]
pub fn m(input: TokenStream) -> TokenStream {
    assert_eq!(input.to_string(), "pub enum E { V = 0, }");
    TokenStream::new()
}
'

echo >repro/src/main.rs '
#[derive(repro::D)]
pub enum E { V = 0x0 }
fn main() {}
'

set -x
cargo +stable check --manifest-path repro/Cargo.toml
cargo +beta check --manifest-path repro/Cargo.toml

     Created binary (application) `repro` package
+ cargo +stable check --manifest-path repro/Cargo.toml
   Compiling repro v0.1.0 (/git/repro/repro)
    Finished dev [unoptimized + debuginfo] target(s) in 0.44s
+ cargo +beta check --manifest-path repro/Cargo.toml
   Compiling repro v0.1.0 (/git/repro/repro)
error: proc-macro derive panicked
 --> src/main.rs:2:10
  |
2 | #[derive(repro::D)]
  |          ^^^^^^^^
  |
  = help: message: assertion failed: `(left == right)`
            left: `"pub enum E { V = 0x0, }"`,
           right: `"pub enum E { V = 0, }"`

error: aborting due to previous error

[petrochenkov]

The change is expected and was introduced in #60679.

Literals, for example hexadecimal literals like 0x0 in the reproduction, are now passed to proc macros precisely (without normalizing to 0) even if they go through "token -> AST -> token" conversion.

Proc macros should be ready to deal with hexadecimal literals because they could previously get them from tokens not going through "token -> AST -> token" conversion (e.g. from fn-like macros).
Looks like the new versions of syn work with literals correctly (#61470 (comment)), so the issue is with an outdated dependency in agatan/squeeze-rs.

[pnkfelix]

triage: Based on @petrochenkov 's analysis above, and the fact that agatan/squeeze-rs itself does not appear to be maintained, I'm going to just accept this as acceptable fallout from PR #60679 and close this ticket, without attempting to post a PR to update the dependency on agatan/squeeze-rs.