Rust-clippy: Ignore generated code

[stepancheg]

Rust-protobuf generates code with several clippy warnings. These warnings are hard to fix, they bother rust-protobuf users, and they actually do need to be fixed (because I know the code is correct).

So the best way to fix the issue in rust-protobuf with clippy would be probably to tell clippy to ignore all clippy warning in some file. However as I understand there is no way to do that.

Clippy could ignore files with comments like "this file is generated" or "ignore clippy".

Note that generated code must be valid even if clippy is not used.

[Manishearth]

However as I understand there is no way to do that.

You can just stick #![allow(clippy)] at the top of the module. There's no need for a magic comments that clippy has to read; Rust's lint infrastructure already has this ability.

You may also need to #![allow(unknown_lints)] on the same file.

[stepancheg]

#![allow(unknown_lints)] hides errors, for example, if rust removes some lint in future version. Otherwise it works. Thanks.

[crusty-dave]

I would expect to be able to do the following in scope:

#![warn(clippy::needless_range_loop, clippy::manual_memcpy)]

or possibly

#[!warn(clippy::needless_range_loop, clippy::manual_memcpy)]

In my case it is reporting a false positive that I would like to suppress, but I would like to use it to check other parts of the source code.

Also: When will clippy be available in stable?

[oli-obk]

In my case it is reporting a false positive that I would like to suppress, but I would like to use it to check other parts of the source code.

You can simply attach #[allow(clippy::foo)] to the item that causes the false positive. Also I suggest you open an issue about the false positive

[jkozlowski]

This all works until I add '-- -D warnings' to the clippy invocation and it upgrades a warning from the compiler and the build. Here's the example:

error: hidden lifetime parameters in types are deprecated
   --> /home/jakubkozlowski/Programming/starfish/target/debug/build/spdk-sys-f36c12b8dbef03e3/out/spdk_bindings.rs:127:29
    |
127 |     fn fmt(&self, fmt: &mut ::std::fmt::Formatter) -> ::std::fmt::Result {
    |                             ^^^^^^^^^^^^^^^^^^^^^- help: indicate the anonymous lifetime: `<'_>`

I have:

#![allow(warnings)]
#![allow(clippy)]
#![allow(unknown_lints)]

Before the include, does anyone know if it's possible to turn off everything for this file, so I can keep -D warnings?

[jamesray1]

You can just stick #![allow(clippy)] at the top of the module. There's no need for a magic comments that clippy has to read; Rust's lint infrastructure already has this ability.

I get the following compiler info with this line from the generated code:

lint name `clippy` is deprecated and may not have an effect in the future. Also `cfg_attr(cargo-clippy)` won't be necessary anymore

note: #[warn(renamed_and_removed_lints)] on by default
help: change it to: clippy::all rustc(renamed_and_removed_lints)

lint name `clippy` is deprecated and may not have an effect in the future. Also `cfg_attr(cargo-clippy)` won't be necessary anymore

help: change it to: clippy::all rustc(renamed_and_removed_lints)

Changing to #![allow(clippy::all)] fixes this. But obviously because this is generated a PR should be made in rust-protobuf. Nevermind, see https://github.com/stepancheg/rust-protobuf/pull/332.

[CreepySkeleton]

Could anyone please explain why we should ever care about code that originates from macro expansions? Such code tends to be redundant, complex, and unclear - but soulless machine does not and should not care about it.

[Manishearth]

Yes, that's what allow(clippy::all) is for. Just use that. Detecting if a file is autogenerated is a can of worms we do not want to open.

[CreepySkeleton]

@Manishearth I'm not talking about auto-generated files, it's about macro expansions. Any chance we may have it?

[Manishearth]

We ignore macro expansions for most lints. File a bug for a specific lint and code example, we can fix it. This is the wrong place for this complaint.

[Rantanen]

allow(clippy::all) works for proc macro expansion as well. Clippy ignores that expansion, until the proc macro goes out of its way and starts expanding using spans from the user code.

I'm currently working for better error messages for my proc macro attributes. My approach is to use spans of user code when expanding the proc macro attribute so that the rustc error messages would point to the bad bits in the user code instead of the #[com_interface] attribute.

This resulted in clippy not ignoring those bits anymore. Google brought me here and allow(clippy::all) provided the solution. I'm now adding that to all the new items that the attribute is expanding to.

(Sorry for the noise, figured I'd clarify this here given this issue was rather high up in Google results.)

[CreepySkeleton]

@Rantanen yes, this is exactly what we did in the end

[Timmmm]

Uhm, is this supposed to work?

warning: unknown lint: `clippy`
 --> src/capnp/mod.rs:1:36
  |
1 | #[allow(non_snake_case, dead_code, clippy)]
  |                                    ^^^^^^
  |
  = note: `#[warn(unknown_lints)]` on by default

Using stable Clippy as of today.

[Timmmm]

Ah right, I see - you have to put #![allow(unknown_lints)] in the file where you do that. A bit of a shame Rust doesn't know about clippy by default, given that it is now included in rustup.

[Manishearth]

@Timmmm no, you need to do #![allow(clippy::all)]. Rustc does know about clippy, but you need to use the namespace