Skip to content

allow only works with some lints if and only if they're allowed both in the crate root and in the desired module #7290

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

Open
T-Dark0 opened this issue May 28, 2021 · 4 comments
Labels
C-bug Category: Clippy is not doing the correct thing

Comments

@T-Dark0
Copy link

T-Dark0 commented May 28, 2021

I tried this code:

// in main.rs
#![warn(clippy::all, clippy::pedantic)]

mod foo;

fn main() {
    foo::foo();
}

//in foo.rs
#![allow(clippy::single_component_path_imports)]

pub fn foo() {
    usable!();
}

macro_rules! usable {
    () => {};
}
use usable;

I expected to see this happen: The lint is silenced for the module

Instead, this happened: The lint was not silenced, and fired anyway in the output of cargo clippy

It may be worth mentioning that the lint is silenced if and only if the allow exists both in the crate root and in the module

This bug also occurs with other lints, but does not occur with all lints: I've been able to cause it with items_after_statements, but not with enum_glob_use or match_same_arms. In the case of the latter two, the lint was silenced for the module without the need to allow it in the crate root as well.

Meta

  • cargo clippy -V: clippy 0.1.54 (1c6868a 2021-05-27)
  • rustc -Vv:
rustc 1.54.0-nightly (1c6868aa2 2021-05-27)
binary: rustc
commit-hash: 1c6868aa21981b37cbd3fc95828ee3b0ac22d494
commit-date: 2021-05-27
host: x86_64-pc-windows-msvc
release: 1.54.0-nightly
LLVM version: 12.0.1
@T-Dark0 T-Dark0 added the C-bug Category: Clippy is not doing the correct thing label May 28, 2021
@camsteffen
Copy link
Contributor

Thanks! Any lints other than single_component_path_imports and items_after_statements not working? This bug will have to be fixed for individual lints.

@danieleades
Copy link

now you mention it, i've seen a similar problem with clippy::print_stderr, where the behaviour is different whether the lint is used in the crate root, or in a module.

see https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/172#note_2767740

@jimblandy
Copy link

This makes Clippy hard to use with generated files, like lalrpop output, because the offending patterns may occur hundreds of times, and the legitimate warnings are hard to find.

Here's another case, with a single source file:

mod foo {
    #![allow(clippy::single_component_path_imports)]
    use regex;

    pub fn foo() {
        regex::Regex::new(r"^\d{4}-\d{2}-\d{2}$").unwrap();
    }
}

fn main() {
    foo::foo();
}

Output:

$ cargo clippy --version
clippy 0.1.61 (fe5b13d 2022-05-18)
$ cargo clippy
warning: this import is redundant
 --> src/main.rs:3:5
  |
3 |     use regex;
  |     ^^^^^^^^^^ help: remove it entirely
  |
  = note: `#[warn(clippy::single_component_path_imports)]` on by default
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#single_component_path_imports

warning: `clippy-bug` (bin "clippy-bug") generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
$ 

@dcecile
Copy link

dcecile commented Aug 11, 2024

Finding that single_component_path_imports = "allow" (lint configuration in Cargo.toml) also doesn't seem to have an effect.

Another way to trigger the effect is to use the command line option: -A clippy::single_component_path_imports

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: Clippy is not doing the correct thing
Projects
None yet
Development

No branches or pull requests

5 participants