Skip to content

bad span on character literal errors #9149

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

Closed
metajack opened this issue Sep 13, 2013 · 1 comment · Fixed by #9308
Closed

bad span on character literal errors #9149

metajack opened this issue Sep 13, 2013 · 1 comment · Fixed by #9308

Comments

@metajack
Copy link
Contributor

When reporting the span for the error it chooses the previous line. This is quite confusing. The error here is that the '\U...' syntax takes exaclty 8 hex digits and 7 are provided.

This test program:

fn main() {
    let c = 'a';
    match c {
        'a' => (),
        'b' => (),
        '\U0123456' => ()
    }
}

produces this output from rustc

$ rustc badspan.rs 
badspan.rs:5:17: 5:18 error: illegal numeric character escape: 39
badspan.rs:5         'b' => (),
                              ^
@ben0x539
Copy link
Contributor

Looks like there's a lot of spots in the lexer where the reported span is the last valid token instead of the offending token. Of the handful rdr.fatal() callers I looked at, just one of them set the right span before the call.

ben0x539 added a commit to ben0x539/rust that referenced this issue Sep 18, 2013
Previously, the lexer calling `rdr.fatal(...)` would report the span of
the last complete token, instead of a span within the erroneous token
(besides one span fixed in 1ac90bb).

This commit adds a few wrappers around `rdr.fatal(...)` that set the
span based on the `StringReader`'s state, give or take, so that all
fatal errors in `libsyntax/parse/lexer.rs` can now report the offending
code more precisely. A number of tests try to verify that, though the
`compile-fail` testing setup can only check that the spans are on the
right lines, and the "unterminated string/block comment" errors can't
have the line marked at all, so that's incomplete.

Closes rust-lang#9149.
bors added a commit that referenced this issue Sep 20, 2013
Previously, the lexer calling `rdr.fatal(...)` would report the span of
the last complete token, instead of a span within the erroneous token
(besides one span fixed in 1ac90bb).

This branch adds wrappers around `rdr.fatal(...)` that sets the span
explicilty, so that all fatal errors in `libsyntax/parse/lexer.rs` now
report the offending code more precisely. A number of tests try to
verify that, though the `compile-fail` testing setup can only check that
the spans are on the right lines, and the "unterminated string/block
comment" errors can't have the line marked at all, so that's incomplete.

This closes #9149.

Also, the lexer errors now report the offending code in the error message,
not just via the span, just like other errors do.
@bors bors closed this as completed in 1019177 Sep 20, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 18, 2022
change applicability type to MaybeIncorrect in `explicit_counter_loop`

close rust-lang#9013

This PR changes  applicability type to `MaybeIncorrect`,  because the suggestion is not `MachineApplicable`.

changelog: change applicability type to MaybeIncorrect in `explicit_counter_loop`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants