Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-110017-format-into-help-deletes-macro.rs:5:10 | LL |      Err(format!("error: {x}")) |          ^^^^^^^^^^^^^^^^^^^^^ expected `Box<dyn Error>`, found `String` | = note: expected struct `Box<dyn std::error::Error>` found struct `String` = note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info) help: call `Into::into` on this expression to convert `String` into `Box<dyn std::error::Error>` | LL |      Err(format!("error: {x}").into()) |                               +++++++ error[E0308]: mismatched types --> $DIR/issue-110017-format-into-help-deletes-macro.rs:23:10 | LL |      Err(outer!(x)) |          ^^^^^^^^^ expected `Box<dyn Error>`, found `String` | = note: expected struct `Box<dyn std::error::Error>` found struct `String` = note: this error originates in the macro `format` which comes from the expansion of the macro `outer` (in Nightly builds, run with -Z macro-backtrace for more info) help: call `Into::into` on this expression to convert `String` into `Box<dyn std::error::Error>` | LL |          format!("error: {}", $x).into() |                                  +++++++ error[E0308]: mismatched types --> $DIR/issue-110017-format-into-help-deletes-macro.rs:41:2 | LL |  entire_fn_outer!(); |  ^^^^^^^^^^^^^^^^^^ expected `Box<dyn Error>`, found `String` | = note: expected struct `Box<dyn std::error::Error>` found struct `String` = note: this error originates in the macro `format` which comes from the expansion of the macro `entire_fn_outer` (in Nightly builds, run with -Z macro-backtrace for more info) help: call `Into::into` on this expression to convert `String` into `Box<dyn std::error::Error>` | LL |              Err(format!("error: {x}").into()) |                                       +++++++ error[E0308]: mismatched types --> $DIR/issue-110017-format-into-help-deletes-macro.rs:51:5 | LL |     nontrivial!(x) |     ^^^^^^^^^^^^^^ expected `Box<dyn Error>`, found `String` | = note: expected struct `Box<dyn std::error::Error>` found struct `String` = note: this error originates in the macro `format` which comes from the expansion of the macro `nontrivial` (in Nightly builds, run with -Z macro-backtrace for more info) help: call `Into::into` on this expression to convert `String` into `Box<dyn std::error::Error>` | LL |         Err(format!("error: {}", $x).into()) |                                     +++++++ error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
The suggestion converts the code to: which is invalid. It should suggest: The suggestion works correctly for non-macro string values. This suggestion was introduced in . No response
It cannot be reproduced on .
I'm able to reproduce it locally. It seems to be suggesting a change in : (note the path) I assume that this is due to macro expansion. It might not be working on the playground because the playground doesn't have the component installed but that's a total guess.
The presence of only affects the human-readable rendering. The important part to me is the JSON output which has even without rust-src. Ideally it would be something closer to what it looks like with :
It seems to affect all macro expansions ():
Is the solution to just disable this suggestion for macro-expanded code? As an aside, perhaps the playground should get , especially because of its prevalence in sharing code which might need the additional context.
I think it's possible to achieve the desired output found in the description, although I'm not sure how exactly. Typically, you would use on the span to peel away the layers of macro invocations, though for that you would need to provide a parent to mark the end of the chain. doesn't need such a stopper but here its use would be incorrect if the macro call itself (e.g. ) was inside of a macro expansion. Since we don't have a parent (afaiaa), earlier I briefly tried to create a parent for via I think but that didn't work. Maybe could work, not sure. This approach is a catch-22 I believe.
Yeah, would that be the desired solution though? Can this be generalized to all the other type mismatch suggestions?
That's a good question. It was mostly an experiment to see if this specific issue can be solved with .