Skip to content
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

Clippy ignores crate wide warn/deny #6610

Closed
tcharding opened this issue Jan 20, 2021 · 13 comments
Closed

Clippy ignores crate wide warn/deny #6610

tcharding opened this issue Jan 20, 2021 · 13 comments
Labels
C-bug Category: Clippy is not doing the correct thing E-hard Call for participation: This a hard problem and requires more experience or effort to work on

Comments

@tcharding
Copy link

tcharding commented Jan 20, 2021

I put this code in main.rs

#![deny(clippy::print_stdout)]

mod foo;

#[allow(clippy::print_stdout)]
fn main() {
    println!("Hello, world!");
}

And this code in foo.rs

pub fn foo() {
    println!("This should trigger clippy");
}

I expected to see clippy warn something like


error: use of `println!`
 --> src/foo.rs:2:5
  |
6 |     println!("This should trigger clippy");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^

Instead all I get is

warning: function is never used: `foo`

Meta

cargo clippy -V                                                                                                            ✘ 101 
clippy 0.1.51 (4253153 2021-01-17)
rustc -Vv
rustc 1.51.0-nightly (4253153db 2021-01-17)
binary: rustc
commit-hash: 4253153db205251f72ea4493687a31e04a2a8ca0
commit-date: 2021-01-17
host: x86_64-unknown-linux-gnu
release: 1.51.0-nightly
LLVM version: 11.0.1
@tcharding tcharding added the C-bug Category: Clippy is not doing the correct thing label Jan 20, 2021
@giraffate
Copy link
Contributor

It seems to be similar to #5356.

@flip1995
Copy link
Member

Yes this is the same underlying issue. The solution is to get rid of pre_expansion_pass lints.

@flip1995 flip1995 added E-hard Call for participation: This a hard problem and requires more experience or effort to work on C-bug Category: Clippy is not doing the correct thing and removed C-bug Category: Clippy is not doing the correct thing labels Jan 26, 2021
@davepacheco
Copy link

I think I ran into this too and reproduced it here: https://github.com/davepacheco/clippy-issue

@giraffate and @flip1995 you said this is the same underlying issue as #5356, but that one looks like it's been fixed. Do you expect this issue is fixed too? I'm still seeing it on clippy 0.0.212 (e1884a8e 2020-12-29) (Rust stable 1.49.0).

This doesn't always seem to be a problem and I'm not sure why not. I have a different crate (dropshot) that uses a crate-wide #![allow(clippy::style)] that appears to work.

@flip1995
Copy link
Member

flip1995 commented Feb 2, 2021

It's the same underlying issue, but requires a separate fix, which involves quite a bit of work. TL;DR the whole lint has to be rewritten.

@davepacheco
Copy link

Thanks for clarifying!

@jszwedko
Copy link

In case it helps others, as a work around I ended up adding these lints to .cargo/config.toml:

[target.'cfg(feature = "cargo-clippy")']
rustflags = [
  "-Dclippy::print_stdout",
  "-Dclippy::print_stderr",
  "-Dclippy::dbg_macro",
]

bors added a commit that referenced this issue Dec 3, 2021
…pansion, r=camsteffen

Updated known problems section for pre-expansion lints about level attributes

Our last three pre-macro expansion lints aren't affected by lint level attributes. This adds a comment to the know problems section of them. I've also updated some CSS to add some spacing after lists on Clippy's lint list:

Before:

![image](https://user-images.githubusercontent.com/17087237/143783579-064326d4-4e58-4d7d-bbe4-fad8b115fcd4.png)

After:

![image](https://user-images.githubusercontent.com/17087237/143783650-9803fa03-c332-4e0e-886f-523d4217c6e6.png)

---

changelog: [`print_stdout`], [`print_stderr`], [`dbg_macro`]: Document how the lint level can be changed and reference #6610

cc: #6610
@Alexendoo
Copy link
Member

@rustbot claim

bors added a commit that referenced this issue Feb 11, 2022
Migrate `dbg_macro` to late pass

changelog: Make `dbg_macro` work with crate level attributes and inside macro calls

One down for #6610, fixes #7275

Also fixes #7274, and adds parenthesis around the suggestion for `dbg!(1, 2, 3)` as it expands to a tuple
@SwishSwushPow
Copy link

My team just stumbled over this problem and we were wondering if we could supply any more information to help solve this issue? Crate wide clippy configuration is quite important for us :)

@flip1995
Copy link
Member

This PR #8518 will reduce the amount of lints that are affected by this issue to this set of lints:

DEPRECATED_CFG_ATTR,
MISMATCHED_TARGET_OS,
EMPTY_LINE_AFTER_OUTER_ATTR,

Are you affected by one of those lints? If not #8518 should fix your issue.

We know why this happens, fixing this is just a huge amount of work or partly impossible, unless we accept major tradeoffs in lint quality. #8518 rewrites multiple lints completely, to give a approximate amount of work that is involved in fixing this.

@SwishSwushPow
Copy link

Oh perfect, thank you for the quick heads up. I was not aware of PR #8518 and how it would affect this issue. We do not use the lints you mentioned, so we should be golden as soon as that is merged :)

@tcharding
Copy link
Author

Thanks for your efforts on this and also the explanations. Can be closed or left open as you think best suits the project.

@flip1995
Copy link
Member

I'll leave it open for visibility at least until we fix this for the remaining lints.

bors added a commit that referenced this issue Sep 14, 2022
Migrate write.rs to a late pass

changelog: Migrates write.rs from a pre expansion pass to a late pass
changelog: [`positional_named_format_parameters`] is renamed in favour of the rustc lint `named_arguments_used_positionally`

- Macros are now identified by diagnostic items, so will no longer lint user defined macros named, e.g. a custom `print!`
- `print_literal`/`write_literal` no longer lint no longer lint literals that come from macro expansions, e.g. `env!("FOO")`
- `print_with_newline`/`write_with_newline` no longer lint strings with any internal `\r` or `\n`s

~~A false negative, `print_literal`/`write_literal` don't lint format strings that produce `FormatSpec`s, e.g. ones containing pretty print/width/align specifiers~~

Suggestion changes:
- ~~`print_literal`/`write_literal` no longer have suggestions, as the spans for the `{}`s were not easily obtainable~~
-  `print_with_newline`/`write_with_newline` has a better suggestion for a sole literal newline, but no longer has suggestions for len > 1 strings that end in a literal newline
- ~~`use_debug` spans are less precise, now point to the whole format string~~

The diff for write.rs is pretty unwieldy, other than for the `declare_clippy_lint!`s I think you'd be better off viewing it as a brand new file rather than looking at the diff, as it's mostly written from scratch

cc #6610, fixes #5721, fixes #7195, fixes #8615
@Alexendoo Alexendoo removed their assignment Oct 15, 2022
@dsherret
Copy link

dsherret commented Mar 9, 2024

This seems to be working now in libraries at least where it wasn't before. I've started using it and it's great.

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 E-hard Call for participation: This a hard problem and requires more experience or effort to work on
Projects
None yet
Development

No branches or pull requests

8 participants