rust-analyzer version: 0.3.2896
rustc version: 1.94.1
editor or extension: VSCode 1.120.0
code snippet to reproduce:
Given a proc-macro like this:
fn generate(input: TokenStream) -> TokenStream
{
let literal = Literal::i32_unsuffixed(-1); // any negative value will do
quote!(const #input: i32 = #literal);
}
And used like generate!(VALUE);, when hovering over the name of the constant there's a popup showing the value. For negative values (as above), this popup shows a value of zero. While further const-eval like const OTHER: i32 = VALUE will inherit the problem, expansions are correct (and if the original macro is expanded, correct values will be shown when hovering over OTHER as well). If this constant is then used in a const-eval match arm, it is treated as zero (again, only when hovering over the result in the editor) but there is no unreachable pattern warning as would be the case with an actual zero value.
The problem disappears when changing the macro to
fn generate(input: TokenStream) -> TokenStream
{
let literal = Literal::i32_unsuffixed(1);
quote!(const #input: i32 = -#literal);
}
This happens despite the fact that, according to debug printout, the two macros produce the same token stream when invoked by rustc.
Note that I did use proc_macro2 for this but it also happens with only proc_macro (the code is just harder to read without quote!). Further, the exact same issue happens for enums, and again there is no warning for the supposed duplicate value. I don't think this is a regression, as I've tried multiple other versions (including pre-release) which had the same issue.
rust-analyzer version: 0.3.2896
rustc version: 1.94.1
editor or extension: VSCode 1.120.0
code snippet to reproduce:
Given a proc-macro like this:
And used like
generate!(VALUE);, when hovering over the name of the constant there's a popup showing the value. For negative values (as above), this popup shows a value of zero. While further const-eval likeconst OTHER: i32 = VALUEwill inherit the problem, expansions are correct (and if the original macro is expanded, correct values will be shown when hovering overOTHERas well). If this constant is then used in a const-eval match arm, it is treated as zero (again, only when hovering over the result in the editor) but there is no unreachable pattern warning as would be the case with an actual zero value.The problem disappears when changing the macro to
This happens despite the fact that, according to debug printout, the two macros produce the same token stream when invoked by rustc.
Note that I did use
proc_macro2for this but it also happens with onlyproc_macro(the code is just harder to read withoutquote!). Further, the exact same issue happens for enums, and again there is no warning for the supposed duplicate value. I don't think this is a regression, as I've tried multiple other versions (including pre-release) which had the same issue.