Skip to content

Extend allow/warn/etc attributes to be applicable to individual use declarations #10534

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

Closed
pnkfelix opened this issue Nov 17, 2013 · 4 comments
Closed
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@pnkfelix
Copy link
Member

Right now, the allow/warn/deny/forbid attributes can only be applied to entire modules.

It would be nice to be able to apply the attributes to individual use declarations, to be able to say, e.g., "I know that this particular import is not currently used in the module, and I do not want to be warned about it; but I do not want to turn off warnings for other imports in the module."

Concrete example:

mod a { pub static x: int = 3; pub static y: int = 4; }

mod b {
    use a::x; // I want to be warned about this one ...
    #[allow(unused_imports)]
    use a::y; // ... but not about this one.
}

mod c {
    #[allow(unused_imports)];
    use a::x; // Insufficient because I get no warning about `x` here.
    use a::y;
}

fn main() {}

(Also, the fact that the syntax is currently accepted when applied to individual use declarations, as above, but seems to be a no-op, is probably also suboptimal. But of course, I would fix the problem by making it have an effect, as described by this ticket.)

@pnkfelix pnkfelix reopened this Nov 17, 2013
@emberian
Copy link
Member

What's the main usecase here?

@pnkfelix
Copy link
Member Author

@cmr The particular instance that I encountered was that I had some code that I commented out temporarily, and that commented out code was the only use of some import among a large set of declarations. I wanted to stop seeing the warnings about that import.

@dcrewi
Copy link
Contributor

dcrewi commented Nov 18, 2013

There is also some issue of consistency about where the setting of lint levels is permitted. Due to the way it's currently implemented, lints that are checked outside of rustc::middle::lint can only have their levels modified by command-line arguments or crate attributes. Lints that are checked from code inside of rustc::middle::lint can, in addition, have their lint levels modified by attributes on any view item, any item or any method. It's probably a good idea for the rules to be the same for all lint checks.

@emberian
Copy link
Member

emberian commented Apr 7, 2014

Still an issue.

bors added a commit that referenced this issue Apr 25, 2014
@bors bors closed this as completed in e72d49a Apr 25, 2014
flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 6, 2023
…llogiq

Flag `bufreader.lines().filter_map(Result::ok)` as suspicious

This lint detects a problem that happened recently in https://github.com/uutils/coreutils and is described in rust-lang#64144.

changelog: [`lines_filter_map_ok`]: new lint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants