-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
It seems to be similar to #5356. |
Yes this is the same underlying issue. The solution is to get rid of |
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 |
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. |
Thanks for clarifying! |
In case it helps others, as a work around I ended up adding these lints to [target.'cfg(feature = "cargo-clippy")']
rustflags = [
"-Dclippy::print_stdout",
"-Dclippy::print_stderr",
"-Dclippy::dbg_macro",
] |
…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
@rustbot claim |
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 :) |
This PR #8518 will reduce the amount of lints that are affected by this issue to this set of lints:
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. |
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 :) |
Thanks for your efforts on this and also the explanations. Can be closed or left open as you think best suits the project. |
I'll leave it open for visibility at least until we fix this for the remaining lints. |
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
This seems to be working now in libraries at least where it wasn't before. I've started using it and it's great. |
I put this code in
main.rs
And this code in
foo.rs
I expected to see clippy warn something like
Instead all I get is
Meta
The text was updated successfully, but these errors were encountered: