Skip to content

Incorrect span when reporting unexpected token #2017

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.

Sign up for GitHub

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

Jump to bottom
Closed
jdm opened this issue Mar 16, 2012 · 0 comments
Closed

Incorrect span when reporting unexpected token #2017

jdm opened this issue Mar 16, 2012 · 0 comments

Comments

@jdm
Copy link
Contributor

jdm commented Mar 16, 2012 

fn main() {
    #error("%?", x);*/
}

yields

rust_dbg2.rs:3:0: 3:1 error: unexpected token: '/'
rust_dbg2.rs:3 }
               ^
@ghost ghost assigned marijnh Mar 20, 2012
@jdm jdm unassigned marijnh Jun 16, 2014
flip1995 pushed a commit to flip1995/rust that referenced this issue May 5, 2020
@bors
Auto merge of rust-lang#5550 - ebroto:manual_non_exhaustive, r=flip1995
cc9088f 
Implement the manual_non_exhaustive lint

Some implementation notes:
* Not providing automatic fixups because additional changes may be needed in other parts of the code, e.g. when constructing a struct.
* Even though the attribute is valid on enum variants, it's not possible to use the manual implementation of the pattern because the visibility is always public, so the lint ignores enum variants.
* Unit structs are also ignored, it's not possible to implement the pattern manually without fields.
* The attribute is not accepted in unions, so those are ignored too.
* Even though the original issue did not mention it, tuple structs are also linted because it's possible to apply the pattern manually.

changelog: Added the manual non-exhaustive implementation lint

Closes rust-lang#2017
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
@celinval
Define --cfg=kani to build docs and only build kani (rust-lang#2017)
6fe52d7 
I removed the `kani_macro` documentation, since all the macros are actually documented as part of `kani` crate because we re-export all `kani_macro` items (and we don't expect users to directly mention / consume `kani_macro`.

I also changed how we invoke `cargo doc` to include `--cfg=kani` so the documentation comes from the macro definition that includes `#[cfg(kani)]`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jdm @marijnh