Skip to content

Unuseful span in type error in some format_args!() invocations #140578

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
m-ou-se opened this issue May 2, 2025 · 2 comments · May be fixed by #140916
Open

Unuseful span in type error in some format_args!() invocations #140578

m-ou-se opened this issue May 2, 2025 · 2 comments · May be fixed by #140916
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-fmt Area: `core::fmt` D-imprecise-spans Diagnostics: spans don't point to exactly the erroneous code E-help-wanted Call for participation: Help is requested to fix this issue. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@m-ou-se
Copy link
Member

m-ou-se commented May 2, 2025

The span of this error is useful:

error[E0282]: type annotations needed
  |
# |     println!("{:?}", []);
  |                      ^^ cannot infer type
  |

However, in a slightly more complicated println, the same error points at the entire macro invocation:

error[E0282]: type annotations needed
  |
# |     println!("{:?} {a} {a:?}", [], a = 1 + 1);
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type
  |

It should have just pointed at [] (or perhaps {:?}), rather than the entire macro call.

The simple println results in this case in format_args lowering:

} else if use_simple_array {
// Generate:
// &[
// <core::fmt::Argument>::new_display(&arg0),
// <core::fmt::Argument>::new_lower_hex(&arg1),
// <core::fmt::Argument>::new_debug(&arg2),
// …
// ]

The more complicated println results in this case in format_args lowering:

} else {
// Generate:
// &match (&arg0, &arg1, &…) {
// args => [
// <core::fmt::Argument>::new_display(args.0),
// <core::fmt::Argument>::new_lower_hex(args.1),
// <core::fmt::Argument>::new_debug(args.0),
// …
// ]
// }

It'd be nice if both cases would cause any type/trait errors to be reported on the argument (or placeholders), instead of on the span of the entire macro invocation.

I'm not sure if this requires changes in rustc_ast_lowering, or in the code that reports the type errors.

@m-ou-se m-ou-se added A-diagnostics Area: Messages for errors, warnings, and lints A-fmt Area: `core::fmt` E-help-wanted Call for participation: Help is requested to fix this issue. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 2, 2025
@jieyouxu jieyouxu added the D-imprecise-spans Diagnostics: spans don't point to exactly the erroneous code label May 2, 2025
@moatom
Copy link

moatom commented May 4, 2025

@m-ou-se
Hi, I'd like to try tackling this issue when I have time because I'm interested in understanding the branching logic that determines how the span is handled in these cases.
Is anyone already working on it? If not, I’ll start looking into it.

P.S. This is my first contribution to the Rust compiler, and I assume this could be a PR with an appropriate level of difficulty. Is that correct?

@m-ou-se
Copy link
Member Author

m-ou-se commented May 4, 2025

@moatom As far as I know, nobody is working on it yet. Your help is welcome.

I'm not sure how difficult solving this will be. It might just need changing some spans in rustc_ast_lowering/src/format.rs, or it might need changing a lot of stuff in the code that generates the "type annotations needed" error.

A big part of the work is going to be trying out a bunch of things and digging through the diagnostics code. Enjoy! ^^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-fmt Area: `core::fmt` D-imprecise-spans Diagnostics: spans don't point to exactly the erroneous code E-help-wanted Call for participation: Help is requested to fix this issue. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants