Promote Certain Lints to Errors in Rust 2021 Edition #80165
Comments
m-ou-se
added
C-tracking-issue
I'm not sure if this one should be deny-by-default; this is what the lint's page says:
|
|
Also, |
|
@rylev GitHub won't let me assign you to this issue; you wanted to work on this, right? I think you can |
This comment has been minimized.
This comment has been minimized.
|
Hmm, I wonder why GitHub won't let us assign rylev directly – they are an org member... |
|
@rustbot claim |
I think these lints belong to a similar category as
The other two (ELLIPSIS_INCLUSIVE_RANGE_PATTERNS and ELIDED_LIFETIMES_IN_PATHS) are related to compatibility or deprecation, and it seems reasonable to deny them in the next edition. (ELIDED_LIFETIMES_IN_PATHS is actually already rejected on async functions.) |
|
unreachable_pub still has bugs after three years: #64762. I don't think it should be even warn-by-default until the false positives are fixed. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Where we are now: Promote to deny:
Do the above need discussion, or are the uncontroversial? Needs more discussion:
Needs implementation work:
|
|
There's also the |
nikomatsakis
added
T-lang
|
I'm nominated this for @rust-lang/lang discussion. I'd like us to review these lints and make sure we are happy with them. |
|
As discussed in the lang meeting: Let's have separate PRs to turn each of these lints into deny-by-default on 2021 (which should be trivial changes), such that each lint can have its down discussion on its own PR. Then we can use this issue as the tracking issue for tracking those PRs. (cc @rylev) |
|
👍 We should also discuss (on an appropriate issue once filed) whether |
|
I will submit PRs for each of these lints. 👍 |
I agree. There are bugfix lints for which the question isn't "make them a hard error in all code or in new code"; the question is "make them a hard error in new code or not at all". |
|
I also just had this idea of making future-incompat lints into hard errors at the edition boundary in #82702. It seems like this is something that should be applied to all future-incompat lints at every edition boundary, independent of whether the warning may be promoted into a hard error in previous editions as well in the future. No maintained code should ever have a future-incompat warning triggering since that code may stop compiling at any point in time, if users are going through the effort of migrating the code to the new edition while keeping code with a future-incompat warning around it seems like there is something going very wrong somewhere. |
Yes, with the caveat that not all future incompat lints can be automatically fixed with |
This is definitely something we should discuss. I don't think we had a frank discussion about future incompatibility lints that are so pervasive that changing them in older code would be too damaging to be practical.
I'm not sure if you're implying that we can only make future imcompat lints errors on edition boundaries if they can be automatically fixed with |
I am not implying this. However, I am implying that edition breakages need to have a proper analysis of what they break, whether those breakages need to be autofixed, and if so, how they will be autofixed. This is something we're working on clarifying in the 2021 edition RFC. Which means that we cannot have a blanket policy of upgrading future incompat lints to edition breakages since this manual analysis must be done as well. |
The problem is that deny-by-default lints can be One possible remedy is to issue a warning when someone allows a deny-by-default lint that is supposed to become a hard error in a future release. For the person that has allowed bare_trait_objects, this means:
|
|
Okay so after going through this discussion I feel like we are retreading a lot of the work done for migration/idiom lints in the last edition, and facing the same dillemmas. We already decided on a lot of this in 2018. There's also some discussion here that seems to redecide lint policy that has been so far never tied to editions. If I recall correctly:
For turning something into a migration lint I really do not see a need to go "one step at a time". The edition involves entirely new things -- never before linted -- being made into hard errors, it should be even less of a problem for things which have been linted for ages. I'll point out,
There is already a stability policy for lints. It is acceptable for lints to randomly change default lint levels without it ever being considered breaking, due to There is a strong distinction between deny-by-default and hard error that is being missed here. deny-by-default is silenceable, and does not break dependencies. On the other hand hard errors are not silenceable and always break dependencies. New hard errors for things which previously compiled or linted are always breaking changes, new deny lints for things which previously compiled or warn-linted are never breaking changes. Turning a warn into a deny never need be tied to an edition, it can be for making people want to do it more. Turning a warn into a hard error almost always must be tied to an edition (or an argument should be made about why the breakage is acceptable and the blast radius should be surveyed -- this happens with future incompat stuff) |
|
I'm not sure if we're including rustdoc lints in this list, but I wonder if it might be a good idea to promote |
|
I don't think those should be denied by default. The documentation still works fine even if the links are broken, and if people care they can always deny the lint themselves. |
Please no, these are not particularly bad, and are sometimes possible to trigger by accident. The bar for deny lints in rustc is pretty high, basically "this is very bad or deprecated" |
|
Closing this as done! Thanks @rylev for pushing on this. |
warning: trait objects without an explicit `dyn` are deprecated
--> src/ignore.rs:48:12
|
48 | Ok(Visitor::ignore())
| ^^^^^^^ help: use `dyn`: `<dyn Visitor>`
|
= note: `#[warn(bare_trait_objects)]` on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2021 edition!
= note: for more information, see issue #80165 <rust-lang/rust#80165>
warning: trait objects without an explicit `dyn` are deprecated
--> src/ignore.rs:58:12
|
58 | Ok(Visitor::ignore())
| ^^^^^^^ help: use `dyn`: `<dyn Visitor>`
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2021 edition!
= note: for more information, see issue #80165 <rust-lang/rust#80165>
=== stdout === === stderr === warning: trait objects without an explicit `dyn` are deprecated --> /home/runner/work/glacier/glacier/ices/86132.rs:4:36 | 4 | const TRAIT_OBJ_UNALIGNED_VTABLE: &Trait = | ^^^^^ help: use `dyn`: `dyn Trait` | = note: `#[warn(bare_trait_objects)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2021 edition! = note: for more information, see issue #80165 <rust-lang/rust#80165> warning: constant is never used: `TRAIT_OBJ_UNALIGNED_VTABLE` --> /home/runner/work/glacier/glacier/ices/86132.rs:4:1 | 4 | / const TRAIT_OBJ_UNALIGNED_VTABLE: &Trait = 5 | | unsafe { mem::transmute((&92u8, &[0b_______001_11i128; 128])) }; | |____________________________________________________________________^ | = note: `#[warn(dead_code)]` on by default error: any use of this value will cause an error --> /home/runner/work/glacier/glacier/ices/86132.rs:5:14 | 4 | / const TRAIT_OBJ_UNALIGNED_VTABLE: &Trait = 5 | | unsafe { mem::transmute((&92u8, &[0b_______001_11i128; 128])) }; | |______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^__- | | | invalid vtable: alignment `7` is not a power of 2 | = note: `#[deny(const_err)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <rust-lang/rust#71800> error: aborting due to previous error; 2 warnings emitted ==============
=== stdout === === stderr === warning: trait objects without an explicit `dyn` are deprecated --> /home/runner/work/glacier/glacier/ices/83630.rs:2:14 | 2 | static DATA: Iterator<Item = _> = "my string"; | ^^^^^^^^^^^^^^^^^^ help: use `dyn`: `dyn Iterator<Item = _>` | = note: `#[warn(bare_trait_objects)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2021 edition! = note: for more information, see issue #80165 <rust-lang/rust#80165> error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> /home/runner/work/glacier/glacier/ices/83630.rs:2:30 | 2 | static DATA: Iterator<Item = _> = "my string"; | ^ not allowed in type signatures error: aborting due to previous error; 1 warning emitted For more information about this error, try `rustc --explain E0121`. ==============
=== stdout === === stderr === warning: trait objects without an explicit `dyn` are deprecated --> /home/runner/work/glacier/glacier/ices/83630.rs:2:14 | 2 | static DATA: Iterator<Item = _> = "my string"; | ^^^^^^^^^^^^^^^^^^ help: use `dyn`: `dyn Iterator<Item = _>` | = note: `#[warn(bare_trait_objects)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2021 edition! = note: for more information, see issue #80165 <rust-lang/rust#80165> error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> /home/runner/work/glacier/glacier/ices/83630.rs:2:30 | 2 | static DATA: Iterator<Item = _> = "my string"; | ^ not allowed in type signatures error: aborting due to previous error; 1 warning emitted For more information about this error, try `rustc --explain E0121`. ============== Co-authored-by: rustbot <rustbot@users.noreply.github.com>
=== stdout ===
=== stderr ===
error: lifetime in trait object type must be followed by `+`
--> /home/runner/work/glacier/glacier/ices/85350.rs:1:26
|
1 | impl FnMut(&Context) for 'tcx {
| ^^^^
error[E0407]: method `print` is not a member of trait `FnMut`
--> /home/runner/work/glacier/glacier/ices/85350.rs:2:5
|
2 | fn print () -> Self :: Output{ }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not a member of trait `FnMut`
error[E0412]: cannot find type `Context` in this scope
--> /home/runner/work/glacier/glacier/ices/85350.rs:1:13
|
1 | impl FnMut(&Context) for 'tcx {
| ^^^^^^^ not found in this scope
|
help: consider importing one of these items
|
1 | use core::task::Context;
|
1 | use std::task::Context;
|
warning: trait objects without an explicit `dyn` are deprecated
--> /home/runner/work/glacier/glacier/ices/85350.rs:1:26
|
1 | impl FnMut(&Context) for 'tcx {
| ^^^^ help: use `dyn`: `dyn 'tcx`
|
= note: `#[warn(bare_trait_objects)]` on by default
= warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021!
= note: for more information, see issue #80165 <rust-lang/rust#80165>
error[E0601]: `main` function not found in crate `85350`
--> /home/runner/work/glacier/glacier/ices/85350.rs:1:1
|
1 | / impl FnMut(&Context) for 'tcx {
2 | | fn print () -> Self :: Output{ }
3 | | }
| |_^ consider adding a `main` function to `/home/runner/work/glacier/glacier/ices/85350.rs`
error[E0224]: at least one trait is required for an object type
--> /home/runner/work/glacier/glacier/ices/85350.rs:1:26
|
1 | impl FnMut(&Context) for 'tcx {
| ^^^^
error[E0261]: use of undeclared lifetime name `'tcx`
--> /home/runner/work/glacier/glacier/ices/85350.rs:1:26
|
1 | impl FnMut(&Context) for 'tcx {
| - ^^^^ undeclared lifetime
| |
| help: consider introducing lifetime `'tcx` here: `<'tcx>`
|
= help: if you want to experiment with in-band lifetime bindings, add `#![feature(in_band_lifetimes)]` to the crate attributes
error[E0229]: associated type bindings are not allowed here
--> /home/runner/work/glacier/glacier/ices/85350.rs:1:6
|
1 | impl FnMut(&Context) for 'tcx {
| ^^^^^^^^^^^^^^^ associated type not allowed here
error[E0212]: cannot use the associated type of a trait with uninferred generic parameters
--> /home/runner/work/glacier/glacier/ices/85350.rs:2:20
|
2 | fn print () -> Self :: Output{ }
| ^^^^^^^^^^^^^^ help: use a fully qualified path with inferred lifetimes: `<[type error] as FnOnce<(&[type error],)>>::Output`
error: aborting due to 8 previous errors; 1 warning emitted
Some errors have detailed explanations: E0212, E0224, E0229, E0261, E0407, E0412, E0601.
For more information about an error, try `rustc --explain E0212`.
==============
=== stdout ===
=== stderr ===
error[E0403]: the name `T` is already used for a generic parameter in this item's generic parameters
--> /home/runner/work/glacier/glacier/ices/86756.rs:1:14
|
1 | trait Foo<T, T = T> {}
| - ^ already used
| |
| first use of `T`
warning: trait objects without an explicit `dyn` are deprecated
--> /home/runner/work/glacier/glacier/ices/86756.rs:3:15
|
3 | eq::<dyn, Foo>
| ^^^ help: use `dyn`: `dyn Foo`
|
= note: `#[warn(bare_trait_objects)]` on by default
= warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021!
= note: for more information, see issue #80165 <rust-lang/rust#80165>
error[E0601]: `main` function not found in crate `86756`
--> /home/runner/work/glacier/glacier/ices/86756.rs:1:1
|
1 | / trait Foo<T, T = T> {}
2 | | fn eq<A, B>() {
3 | | eq::<dyn, Foo>
4 | | }
| |_^ consider adding a `main` function to `/home/runner/work/glacier/glacier/ices/86756.rs`
error[E0224]: at least one trait is required for an object type
--> /home/runner/work/glacier/glacier/ices/86756.rs:3:10
|
3 | eq::<dyn, Foo>
| ^^^
error[E0107]: missing generics for trait `Foo`
--> /home/runner/work/glacier/glacier/ices/86756.rs:3:15
|
3 | eq::<dyn, Foo>
| ^^^ expected at least 1 generic argument
|
note: trait defined here, with at least 1 generic parameter: `T`
--> /home/runner/work/glacier/glacier/ices/86756.rs:1:7
|
1 | trait Foo<T, T = T> {}
| ^^^ -
help: add missing generic argument
|
3 | eq::<dyn, Foo<T>>
| ^^^^^^
error: aborting due to 4 previous errors; 1 warning emitted
Some errors have detailed explanations: E0107, E0224, E0403, E0601.
For more information about an error, try `rustc --explain E0107`.
==============
|
“dyn” this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2021 edition! |
Tracking issue for turning lints into errors in Rust 2021.
BARE_TRAIT_OBJECTSELLIPSIS_INCLUSIVE_RANGE_PATTERNScc @rylev
The text was updated successfully, but these errors were encountered: