Skip to content
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

Typoing dot instead of comma in println! gives a warning at the wrong place #75492

Closed
vivia opened this issue Aug 13, 2020 · 2 comments · Fixed by #75779
Closed

Typoing dot instead of comma in println! gives a warning at the wrong place #75492

vivia opened this issue Aug 13, 2020 · 2 comments · Fixed by #75779
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The parsing of Rust source code to an AST C-enhancement Category: An issue proposing an enhancement or a PR with one. D-terse Diagnostics: An error or lint that doesn't give enough information about the problem at hand. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@vivia
Copy link

vivia commented Aug 13, 2020

use std::time::SystemTime;

fn main() {
    println!("Hello, {:?}!". SystemTime::now());
}

says:

error: expected token: `,`
 --> src/main.rs:4:40
  |
4 |     println!("Hello, {:?}!". SystemTime::now());
  |                                        ^^ expected `,`

... which isn't exactly where the , was expected.

(Playground)

Another variation is this code:

fn random_xkcd_number () -> i32 {
    4
}

fn main() {
    println!("Hello, {}!". random_xkcd_number());
}

which gives this result:

error: format argument must be a string literal
 --> src/main.rs:6:14
  |
6 |     println!("Hello, {}!". random_xkcd_number());
  |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
help: you might be missing a string literal to format with
  |
6 |     println!("{}", "Hello, {}!". random_xkcd_number());
  |              ^^^^^

(Playground)

@jonas-schievink jonas-schievink added the A-diagnostics Area: Messages for errors, warnings, and lints label Aug 13, 2020
@JohnTitor JohnTitor added A-parser Area: The parsing of Rust source code to an AST C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. D-terse Diagnostics: An error or lint that doesn't give enough information about the problem at hand. labels Aug 13, 2020
@scrabsha
Copy link
Contributor

Hello,
I am a quite new contributor, and I'd like to tackle this issue. Do you think that is possible?

I have looked a bit at the code, and I think this mostly comes from the parse_args function, more precisely, this condition can be tweaked. Is that correct?

@scrabsha
Copy link
Contributor

I have looked a bit at the code, and I think this mostly comes from the parse_args function, more precisely, this condition can be tweaked. Is that correct?

Turns out I was terribly wrong. The problem is that the following snippet:

println!("A number: {}". std::iter::once(42).next().unwrap());

Can be rewritten as:

println!("A number: {}".std ::iter::once(42).next().unwrap());

And that the parse_args function looks for an expression as the first argument (corresponding code, code example). Consequently, "A number: {}".std is the said expression, which explain why the error is raised on the first ::.

Now that I know where the error comes from. I think the best way to fix this issue is to check if this expression can be a format string, perhaps with the expr_to_spanned_string function. I am still unsure about the quality of the emitted error, but at least it would have the correct span.

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-parser Area: The parsing of Rust source code to an AST C-enhancement Category: An issue proposing an enhancement or a PR with one. D-terse Diagnostics: An error or lint that doesn't give enough information about the problem at hand. 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.

4 participants