-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Properly handle different defaults for severity of lints #18466
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
Properly handle different defaults for severity of lints #18466
Conversation
8427cf3 to
7aebc12
Compare
| //! The edition of the Rust language used in a crate. | ||
| // Ideally this would be defined in the span crate, but the dependency chain is all over the place | ||
| // wrt to span, parser and syntax. | ||
| // This should live in a separate crate because we use it in both actual code and codegen. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just include! this file in xtask instead? I personally don't really like this small thing being a crate. Or just duplicate what we need given its not much
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want to duplicate because then adding edition will need to touch both. But include!() seems fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works for rustc but r-a is unable to find the file both with #[path = "..."] mod edition; and with include!(), do you know why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahaha, right. This fails in r-a because the include lies outside of the source root of the crate itself so we fail to resolve the path... This is one of the outstanding problems with our VFS system
In that case I guess we can stay with the crate for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@rustbot ready
e30ed15 to
7aebc12
Compare
|
☔ The latest upstream changes (presumably #18662) made this pull request unmergeable. Please resolve the merge conflicts. |
7aebc12 to
185fcc9
Compare
Previously all lints were assumed to be `#[warn]`, and we had a hand-coded list of `#[allow]` exceptions. Now the severity is autogenerated from rustdoc output. Also support lints that change status between editions, and the `warnings` lint group.
185fcc9 to
0b7a6f3
Compare
|
@Veykril can you re-approve? Thanks. |
|
I cannot reproduce the failure locally - @Veykril do you have any idea what's going on? |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Oh no are we still racing in that test? |
Previously all lints were assumed to be
#[warn], and we had a hand-coded list of#[allow]exceptions. Now the severity is autogenerated from rustdoc output.Also support lints that change status between editions, and the
warningslint group.Fixes #18462.