Found unstable fingerprints for def_ident_span
#95945
Comments
jessa0
added
C-bug
|
Bisection points to #93095 for this, but it may be a different manifestation of the earlier issue the PR was supposed to fix ? |
|
Since this repro depends on |
Here's a minimal proc-macro-derive: use proc_macro::TokenStream;
use quote::quote;
use syn::{parse_macro_input, Data, DataEnum, DeriveInput};
#[proc_macro_derive(Bar)]
pub fn derive_bar(input: TokenStream) -> TokenStream {
let DeriveInput { ident, data, .. } = parse_macro_input!(input as DeriveInput);
match data {
Data::Enum(DataEnum { variants, .. }) => {
let constants = variants.iter().map(|variant| {
quote! {
const #variant: () = ();
}
});
quote! {
impl #ident {
#(#constants)*
}
}
.into()
}
_ => panic!(),
}
}And here's the code to compile incrementally (before): #[derive(foo_macros::Bar)]
pub enum FooEnum { One }and after: #[derive(foo_macros::Bar)]
pub enum FooEnum { Zero, One }I couldn't manage to reproduce it by just passing in idents to a regular proc-macro. I'm not sure how to best eliminate |
|
Note: this issue was fixed by #95656 which will be available in tomorrow's nightly. |
lqd
added
the
E-needs-test
|
I have a minimized test locally - unfortunately, ai don't think it can be made to work with the revision system. I work on converting to a run-make test that manually edits the file. |
Recompiling this minimal example using
rustc 1.60.0 (7737e0b5c 2022-04-04)orrustc 1.62.0-nightly (1f7fb6413 2022-04-10)crashes withFound unstable fingerprints for def_ident_span(foo[c936]::{impl#0}::deserialize::{impl#0}::One): Some(src/lib.rs:5:5: 5:8 (#0)):Code
Since this is an incremental compilation bug, there are "before" and "after" code snippets, where a
cargo buildhappens on the "before" snippet and then on the "after" snippet.Before
Unexpanded:
Expanded (via
cargo-expand):After
Unexpanded:
Expanded (via
cargo-expand):Meta
rustc --version --verbose:rustc +nightly --version --verbose:Error output
Before
After
Backtrace
The text was updated successfully, but these errors were encountered: