forbid overwritten by later allow on the same "scope level"
#70819
Comments
|
This is in fact a stable-to-beta regression: with Rust 1.42, the code still gets rejected as expected. |
jonas-schievink
added
A-frontend
|
Likely regression candidate: #67885 |
|
Interestingly, doing the same via flags in the source code also does not work as expected -- the #![forbid(unused)]
#![allow(unused)]
fn square(num: i32) -> i32 {
num * num
}This is also a regression, but not a recent one: with Rust 1.20, the code gets rejected as expected; with Rust 1.21 and later it gets accepted. It is also in direct contradiction with the documentation which says
|
rustbot
added
the
ICEBreaker-Cleanup-Crew
|
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good cc @AminArria @chrissimpkins @contrun @DutchGhost @elshize @ethanboxx @h-michael @HallerPatrick @hdhoang @hellow554 @imtsuki @jakevossen5 @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @senden9 @shekohex @sinato @spastorino @turboladen @woshilapin @yerke |
|
Assigning |
|
Nominating also according to what was discussed during the meeting for |
spastorino
added
I-nominated
T-lang
|
Note that there are two separate regressions going on:
|
|
I opened #70918 to address the CLI argument regression |
|
Bisect of inline attributes: Checking for commit hashes in that nightly and the one before Commits by bors in that range: |
…vidtwco rustc_session: forbid lints override regardless of position Addresses the regression reported in rust-lang#70819 for command line arguments, but does not address the source code flag regression.
|
@AminArria thanks a lot! I would guess the most likely regression candidate is #43522, then. My guess would be that somewhere around here, lint groups are not handled properly. This code looks different from the previous Cc @alexcrichton @michaelwoerister (PR author and reviewer)... but this is from 2017 so I doubt they will remember many details. ;) Cc @rust-lang/wg-diagnostics for people with lint knowledge. |
|
I'm not sure I have a ton to add here myself, this definitely feels like a bug (both CLI and attribute handling) and seems reasonable to fix, and the fix is likely the same for both. |
|
Turns out the problem is not about lint groups, it is about #![forbid(unused)]
#[allow(unused)]
fn square(num: i32) -> i32 {
num * num
} |
RalfJung
changed the title
forbid overwritten by later allow on the same "scope level"
RalfJung
added
the
regression-from-stable-to-stable
…ide-forbid-in-same-scope, r=petrochenkov Disallow later override of forbid lint in same scope Fix rust-lang#70819 When building lint specs map for a given scope, check if forbid present on each insert. Drive-by changes: 1. make `LintLevelsBuilder::push` private to the crate. 2. Add methods to `LintSource` for extracting its name symbol or its span. 3. Rewrote old test so that its use of lint attributes are consistent with what we want in the language. (Note that the fact this test existed is a slight sign that we may need a crater run on this bugfix...)
…ide-forbid-in-same-scope, r=petrochenkov Disallow later override of forbid lint in same scope Fix rust-lang#70819 When building lint specs map for a given scope, check if forbid present on each insert. Drive-by changes: 1. make `LintLevelsBuilder::push` private to the crate. 2. Add methods to `LintSource` for extracting its name symbol or its span. 3. Rewrote old test so that its use of lint attributes are consistent with what we want in the language. (Note that the fact this test existed is a slight sign that we may need a crater run on this bugfix...)
…ide-forbid-in-same-scope, r=petrochenkov Disallow later override of forbid lint in same scope Fix rust-lang#70819 When building lint specs map for a given scope, check if forbid present on each insert. Drive-by changes: 1. make `LintLevelsBuilder::push` private to the crate. 2. Add methods to `LintSource` for extracting its name symbol or its span. 3. Rewrote old test so that its use of lint attributes are consistent with what we want in the language. (Note that the fact this test existed is a slight sign that we may need a crater run on this bugfix...)
|
The PR fixing this (#73379) was closed due to inactivity. |
|
I can do that. |
…w-override-forbid-in-same-scope, r=petrochenkov Disallow overriding forbid in same scope Rebased rust-lang#73379. Fixes rust-lang#70819.
Previously, cap-lints was ignored when checking the previous forbid level, which meant that it was a hard error to do so. This is different from the normal behavior of lints, which are silenced by cap-lints; if the forbid would not take effect regardless, there is not much point in complaining about the fact that we are reducing its level. It might be considered a bug that even `--cap-lints deny` would suffice to silence the error on overriding forbid, depending on if one cares about failing the build or precisely forbid being set. But setting cap-lints to deny is quite odd and not really done in practice, so we don't try to handle it specially. This also unifies the code paths for nested and same-level scopes. However, the special case for CLI lint flags is left in place (introduced by rust-lang#70918) to fix the regression noted in rust-lang#70819. That means that CLI flags do not lint on forbid being overridden by a non-forbid level. It is unclear whether this is a bug or a desirable feature, but it is certainly inconsistent. CLI flags are a sufficiently different "type" of place though that this is deemed out of scope for this commit.
…kfelix Use true previous lint level when detecting overriden forbids Previously, cap-lints was ignored when checking the previous forbid level, which meant that it was a hard error to do so. This is different from the normal behavior of lints, which are silenced by cap-lints; if the forbid would not take effect regardless, there is not much point in complaining about the fact that we are reducing its level. It might be considered a bug that even `--cap-lints deny` would suffice to silence the error on overriding forbid, depending on if one cares about failing the build or precisely forbid being set. But setting cap-lints to deny is quite odd and not really done in practice, so we don't try to handle it specially. This also unifies the code paths for nested and same-level scopes. However, the special case for CLI lint flags is left in place (introduced by rust-lang#70918) to fix the regression noted in rust-lang#70819. That means that CLI flags do not lint on forbid being overridden by a non-forbid level. It is unclear whether this is a bug or a desirable feature, but it is certainly inconsistent. CLI flags are a sufficiently different "type" of place though that this is deemed out of scope for this commit. r? `@pnkfelix` perhaps? cc rust-lang#77713 -- not marking as "Fixes" because of the lack of proper unused attribute handling in this PR
|
Maybe? It is worth trying, but I don't know that code very well. EDIT: By "it" I mean removing the |
|
Unfortunately not, it seems. With the following input file: fn main() {
let a = 5;
}I get, on current nightly with which is actually suboptimal, because there is no warning about the In any case, with the following patch applied and the same command line arguments: diff --git a/compiler/rustc_session/src/config.rs b/compiler/rustc_session/src/config.rs
index f517c483758..436afad11b8 100644
--- a/compiler/rustc_session/src/config.rs
+++ b/compiler/rustc_session/src/config.rs
@@ -1161,15 +1161,7 @@ pub fn get_cmd_lint_options(
let mut describe_lints = false;
for &level in &[lint::Allow, lint::Warn, lint::Deny, lint::Forbid] {
- for (passed_arg_pos, lint_name) in matches.opt_strs_pos(level.as_str()) {
- let arg_pos = if let lint::Forbid = level {
- // HACK: forbid is always specified last, so it can't be overridden.
- // FIXME: remove this once <https://github.com/rust-lang/rust/issues/70819> is
- // fixed and `forbid` works as expected.
- usize::MAX
- } else {
- passed_arg_pos
- };
+ for (arg_pos, lint_name) in matches.opt_strs_pos(level.as_str()) {
if lint_name == "help" {
describe_lints = true;
} else {I get no warnings and no errors (incorrectly, because |
Yeah that's wrong... so the FIXME is still accurate, though I am not sure why. |
|
I'm going to briefly re-open this issue -- I don't remember what we decided about |
|
Arguably this shouldn't be assigned to me anymore. Its possible we may want to close this and open a fresh issue (potentially a P-medium one, or just freshly re-prioritized) dedicated to the command line interactions between -F and -A |
forbidis not honored when it is followed by anallowon the same "scope level". This compiles, but should fail:If we move the
allowdown to the function level, it fails to compile as expected:The same issue also arises with CLI arguments, which all share the "scope level". That was worked around with in #70918, but once the above is fixed, that hack can likely be removed.
Original description
According to my understanding, the purpose of
-F/forbidfor lints is that they can not be allowed any more. Thus I would expect that calling rustc with-Funused -Aunusedwill fail when there is unused code in the file.However, that is not the case: with that sequence of arguments, unused code is silently accepted.
Cc Manishearth/compiletest-rs#216
The text was updated successfully, but these errors were encountered: