Ability to skip files or blocks entirely

[danielparks]

Description

Some experimental code of mine generates a 48,000+ line function¹ that takes 20+ minutes to process with Clippy with all lints allowed.

It would be really helpful to be able to skip or ignore files or blocks of code entirely.

This seems like a fairly niche use-case, so perhaps this isn’t worth pursuing.

Discarded idea: using a feature

I considered adding a clippy feature, but this is a bit inconvenient. I usually run cargo clippy --all-features so hiding the code if feature = "clippy" works well, but I also run cargo test --all-features so I need to change one or the other. This is additionally complicated by needing to configure CI correctly.

These are not insurmountable problems at all, but they do make it harder, especially for new people who want to contribute to my project.

Proposal: setting --cfg clippy when Clippy runs

Code that you don’t want Clippy to look at could be guarded with #[cfg(not(clippy))].

I haven’t dug into the Clippy code yet, but this seems like it might be relatively easy to implement (I’m happy to volunteer).

I’m not sure if Clippy would need an option to disable the configuration option so that you can force it to look at all code. For my usage, I would be happy to just remove the #[cfg(not(clippy))] line and run clippy again, but I could imagine that some people would want to run Clippy on some code only some times.

I suppose another solution would be for cargo clippy to accept --cfg options.

Version

rustc 1.66.1 (90743e729 2023-01-10)
binary: rustc
commit-hash: 90743e7298aca107ddaa0c202a4d3604e29bfeb6
commit-date: 2023-01-10
host: x86_64-apple-darwin
release: 1.66.1
LLVM version: 15.0.2

Additional Labels

@rustbot label +C-enhancement

Footnotes

1. The code is actually used in a private branch on another crate, but there is an example that generates the function. This is all a bit horrific, and I’m still considering just shelving the idea, but it’s much faster than anything else I’ve tried. ↩

[danielparks]

FWIW, just building the code takes less than 30 seconds additional, so it’s not just a matter of Rust taking a long time with a lot of code.

[smoelius]

What commands should one use to reproduce the 20+ minute run? (When I just git clone ..., cd iter-matcher, and cargo clippy, it finishes almost instantaneously.)

[danielparks]

iter-matcher just generates code, it doesn’t build it. I published a branch on another crate to demonstrate. I'll try to keep it clean, but this is all under active development.

git clone --branch slow-clippy https://github.com/danielparks/htmlize.git
cd htmlize
cargo clippy --all-features

[smoelius]

Based on a cursory analysis, this appears to be where the time is spent:

    at clippy_utils/src/mir/transitive_relation.rs:21
    at clippy_utils/src/mir/possible_borrower.rs:48
    at clippy_utils/src/mir/possible_borrower.rs:190
    at clippy_lints/src/redundant_clone.rs:85

These line numbers are with respect to the latest nightly (e0ee58b).

This is an area of code actively being worked on for other reasons (see #10134). Hopefully, we'll have a fix soon. (cc: @Jarcho)

[Alexendoo]

In the meanwhile, clippy does pass --cfg cargo-clippy so you could use #[cfg(not(feature = "cargo-clippy"))]. That does need documenting somewhere

[danielparks]

@Alexendoo that works, thanks! (FWIW, it would have to pass --cfg 'feature="cargo-clippy"').

I guess all that remains is documenting it somewhere. I’ll try to take a crack at that in the next few days (if nobody beats me to it).

[danielparks]

I’ve renamed the iter-matcher crate to matchgen, so here are the new instructions for reproducing the slow Clippy behavior:

git clone --branch slow-clippy https://github.com/danielparks/matchgen.git
cd matchgen
cargo clippy

It took 22 minutes on my machine. This generates code with #[allow(clippy::all)]. The code that generates the big function is in matchgen_tests/build.rs; it generates $OUT_DIR/test-matchers.rs.

I figure that a function that’s tens of thousands of lines long isn’t a very high priority, but I’ll reinvestigate and possibly produce a minimal test case once #10134 is finished. (This can’t be the same issue because it’s in stable Clippy, but it sounds like it may be in code that’s going to be significantly changed anyway.)