Compiler suggests #[derive((DeriveMacro).try_into().unwrap())]

[msrd0]

Today I encountered a rather unhelpful suggestion from the compiler (1.47.0):

error[E0308]: mismatched types                                                                                                                                                                                                                                               
 --> src/lib.rs:3:10                                                                                                                                                                                                                              
  |                                                                                                                                                                                                                                                                          
3 | #[derive(DeriveMacro)]                                                                                                                                                                                                                                                      
  |          ^^^^^^^^^^^ expected `usize`, found `i32`                                                                                                                                                                                                                          
  |                                                                                                                                                                                                                                                                          
  = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)                                                                                                                                                             
help: you can convert an `i32` to `usize` and panic if the converted value wouldn't fit                                                                                                                                                                                      
  |                                                                                                                                                                                                                                                                          
3 | #[derive((DeriveMacro).try_into().unwrap())]                                                                                                                                                                                                                                
  |   

The code emited from the derive macro contains something along the lines of let value: usize = -1 as i32.

Applying the suggestion, however, doesn't really help (almost as if I had to fix the problem in the derive macro):

error: malformed `derive` attribute input
 --> src/lib.rs:3:1
  |
3 | #[derive((DeriveMacro).try_into().unwrap())]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: missing traits to be derived: `#[derive(Trait1, Trait2, ...)]`

I believe the compiler should only emit that suggestion if the code it applies to is actually an expression of type i32.

[Aaron1011]

@msrd0 In general, there's not much that the compiler can do in this type of situation - it's up to the proc-macro to emit tokens with reasonable spans.

Is DeriveMacro the actual name of the macro you're invoking? Are you able to share your repository, or a link to the crate that defines the macro you're invoking?

[msrd0]

This is a small extract of my macro that reproduces the error and suggestion: https://github.com/msrd0/proc-macro-try-into-suggestion

I believe the let value: usize part should have a span of the macro's call site (#[derive(DeriveMacro)]) while -1 as i32 should point into the non-derive code (#[custom = "{ -1 as i32 }"]), not sure which span is important here.

So maybe this would've been a better suggestion, eventhough the code will always panic:

help: you can convert an `i32` to `usize` and panic if the converted value wouldn't fit                                                                                                                                                                                      
  |                                                                                                                                                                                                                                                                          
4 | #[custom = "{ (-1 as i32).try_into().unwrap() }"]                                                                                                                                                                                                                                
  |   

[msrd0]

Still, the error message is unhelpful even if the code was completely unrelated to the macro's input and hence cannot point to a reasonable span outside of the generated code. So maybe, if the only available span is that of the call site, do not emit any suggestion?

[msrd0]

Testing this further, it seems that the compiler is confused by the span of every token in -1 as i32 pointing to the string literal "-1 as i32". If I used my own variation of syn::Meta that allows syn::Expr instead of syn::Lit, I was able to get #[custom = (-1 as i32).try_into().unwrap())] for input #[custom = -1 as i32] as the suggestion, which is actually what I'd expect.

[danielhenrymantilla]

Yes, I don't think spans can point inside a string literal, at least not in stable Rust. The best you could achieve is to manually respan the parsed TokenStream from the LitStr with the span of that very LitStr (otherwise it defaults to the call_site() span), but then it would suggest doing: #[custom = "-1 as i32".try_into().unwrap()]. So, if you care about the suggestion being on-point, and on stable Rust, you should indeed use a syntax that does not take a string literal but a code block, something like: #[custom = { -1 as i32 }] or even #[custom = || { -1 as i32 }] so that the "non evaluated" nature is more explicit.

---

w.r.t. the compiler, maybe some mechanism to express there is no actual span to apply suggestions to would be useful, so that you could use a LitStr (with an overridden span) and expect a message along the lines of:

error[E0308]: mismatched types                                                                                                                                                                                                                                               
 --> src/lib.rs:3:10                                                                                                                                                                                                                              
  |                                                                                                                                                                                                                                                                          
3 | #[derive(CustomMacro)]
4 | #[custom = "-1 as i32"]
  |            ^^^^^^^^^^^ expected `usize`, found `i32`                                                                                                                                                                                                                          
  |                                                                                                                                                                                                                                                                          
  = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info) 

[msrd0]

The best you could achieve is to manually respan the parsed TokenStream from the LitStr with the span of that very LitStr

I didn't know that syn already supported this, but quote_spanned!(expr_span => #expr_parsed) should do exactly the same. Still, the compiler applies the suggestion to the call site and not the str.

w.r.t. the compiler, maybe some mechanism to express there is no actual span to apply suggestions to

This is probably the behaviour I expected to begin with when the span is that of the call site.

[phansch]

fwiw, I believe we're running into similar issues with various Clippy lints:

• Macro-generated code triggers suspicious-else-formatting rust-clippy#6249
• unit_arg lint for Rocket handlers returning unit causes a warning rust-clippy#6514

AIUI, there is currently no way to tell if a span originated from quote_spanned usage, right?