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

Ignore generated code #702

Closed
stepancheg opened this issue Feb 23, 2016 · 19 comments
Closed

Ignore generated code #702

stepancheg opened this issue Feb 23, 2016 · 19 comments

Comments

@stepancheg
Copy link

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
Copy link
Member

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
Copy link
Author

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

baumanj referenced this issue in habitat-sh/habitat May 29, 2018
… errors for

Code generated by protobuf contains #![allow(clippy)] directives, which are
incompatible with setting any clippy lints as forbidden. Using deny instead
gives errors in other context, but still allows the generated code to suppress
output we're not interested in.

See https://github.com/Manishearth/rust-clippy/issues/702 for more on why the
generated code needs to allow clippy lints to be ignored.

Signed-off-by: Jon Bauman <5906042+baumanj@users.noreply.github.com>
baumanj referenced this issue in habitat-sh/habitat May 29, 2018
… errors for

Code generated by protobuf contains #![allow(clippy)] directives, which are
incompatible with setting any clippy lints as forbidden. Using deny instead
gives errors in other context, but still allows the generated code to suppress
output we're not interested in.

See https://github.com/Manishearth/rust-clippy/issues/702 for more on why the
generated code needs to allow clippy lints to be ignored.

Signed-off-by: Jon Bauman <5906042+baumanj@users.noreply.github.com>
baumanj referenced this issue in habitat-sh/habitat May 31, 2018
… errors for

Code generated by protobuf contains #![allow(clippy)] directives, which are
incompatible with setting any clippy lints as forbidden. Using deny instead
gives errors in other context, but still allows the generated code to suppress
output we're not interested in.

See https://github.com/Manishearth/rust-clippy/issues/702 for more on why the
generated code needs to allow clippy lints to be ignored.

Signed-off-by: Jon Bauman <5906042+baumanj@users.noreply.github.com>
baumanj referenced this issue in habitat-sh/habitat Jun 1, 2018
… errors for

Code generated by protobuf contains #![allow(clippy)] directives, which are
incompatible with setting any clippy lints as forbidden. Using deny instead
gives errors in other context, but still allows the generated code to suppress
output we're not interested in.

See https://github.com/Manishearth/rust-clippy/issues/702 for more on why the
generated code needs to allow clippy lints to be ignored.

Signed-off-by: Jon Bauman <5906042+baumanj@users.noreply.github.com>
@crusty-dave
Copy link

crusty-dave commented Sep 5, 2018

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
Copy link
Contributor

oli-obk commented Sep 6, 2018

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
Copy link

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
Copy link

jamesray1 commented Dec 31, 2018

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 stepancheg/rust-protobuf#332.

@CreepySkeleton
Copy link

CreepySkeleton commented Sep 19, 2019

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
Copy link
Member

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
Copy link

CreepySkeleton commented Sep 19, 2019

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

@Manishearth
Copy link
Member

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
Copy link
Contributor

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
Copy link

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

@Timmmm
Copy link

Timmmm commented Jun 22, 2020

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
Copy link

Timmmm commented Jun 22, 2020

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
Copy link
Member

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

@AsadullahFarooqi
Copy link

AsadullahFarooqi commented Jan 28, 2023

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.

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.

I'm trying to disable clippy on auto-generated protobuf (tokio-rs/prost) but not sure what to do, I've tried the above suggestions but it still gives warnings on auto-generated files. I've tried #allow(clippy::all) the builder.rs
https://github.com/AsadullahFarooqi/lance/tree/main/rust

it throws warns on target lance/rust/target/debug/build/lance-0c7c3136d2cedec9/out/lance.format.pb.rs:242:13 where the generated code is placed

@llogiq
Copy link
Contributor

llogiq commented Jan 29, 2023

There is no builder.rs file in that repo. Are you sure you have the #[allow(clippy::all)] in the generated code or in a module above?

@AsadullahFarooqi
Copy link

AsadullahFarooqi commented Jan 29, 2023

@llogiq
here is the builder.rs link
https://github.com/eto-ai/lance/blob/main/rust/build.rs
the generated code is used in the src/index.rs and src/format.rc

@Manishearth
Copy link
Member

You need to either

  • have #![allow(clippy::all)] (note the exclamation mark) at the top of the generated file
  • have #[allow(clippy::all)] (no exclamation mark) on the mod statement pointing to the generated code

We can't really help you without being able to see the generated code or how it's pulled in

Xanewok added a commit to Xanewok/slang that referenced this issue Aug 3, 2023
...however Clippy does not honor the @generated and needs an explicit
allow setting, see rust-lang/rust-clippy#702.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests