dtolnay / noisy-clippy Goto Github PK

For example rust-lang/rust-clippy#8621.

Currently we are producing separate counts and html pages for eval_order_dependence and mixed_read_write_in_expression.

This might require a PR to clippy to include all past names of lints in https://rust-lang.github.io/rust-clippy/master/lints.json. Currently it just has the past named mentioned in unstructured form in the lint description.

  {
    "id": "mixed_read_write_in_expression",
    "id_span": {
      "path": "src/mixed_read_write_in_expression.rs",
      "line": 45
    },
    "group": "restriction",
    "level": "allow",
    "docs": "\n### What it does\nChecks for a read and a write to the same variable where\nwhether the read occurs before or after the write depends on the evaluation\norder of sub-expressions.\n\n### Why is this bad?\nIt is often confusing to read. As described [here](https://doc.rust-lang.org/reference/expressions.html?highlight=subexpression#evaluation-order-of-operands),\nthe operands of these expressions are evaluated before applying the effects of the expression.\n\n### Known problems\nCode which intentionally depends on the evaluation\norder, or which is correct for any evaluation order.\n\n### Example\n```rust\nlet mut x = 0;\n\nlet a = {\n    x = 1;\n    1\n} + x;\n// Unclear whether a is 1 or 2.\n```\n\nUse instead:\n```rust\nlet tmp = {\n    x = 1;\n    1\n};\nlet a = tmp + x;\n```\n### Past names\n\n* `eval_order_dependence`\n\n",
    "version": "pre 1.29.0",
    "applicability": {
      "is_multi_part_suggestion": false,
      "applicability": "Unresolved"
    }
  },

Crates that predate the introduction of "tool attributes" like allow(clippy::thing) into Rust syntax use this older idiom instead. See for example the serde crate: https://github.com/serde-rs/serde/blob/v1.0.130/serde/src/lib.rs#L99-L140

To see which lints are most popular.

The current implementation of this crate expects a single flat directory with all the .crate files (100,000 – 700,000 of them currently on crates.io…).

https://github.com/dtolnay/get-all-crates produces a nested structure that works more like how Cargo's registry index is arranged. It would be better to use that, and update the documentation of noisy-clippy to point to get-all-crates for how to obtain all the crate files.

Hi David,

What does it mean when the lints are crossed out in your table ?

I could not find a clear explanation.
Are those the lints that used to be in the default and got downgraded to opt-in ?

For example too_many_arguments: it would be relevant to know the distribution of number of arguments among functions where this lint is being suppressed. The current default threshold in Clippy is 7. Is it the case that almost all suppression are using 8 arguments, or 8 or 9? Or is it a much wider distribution? That would be relevant for informing a choice of better default.

Similarly type_complexity: what is the distribution of actual complexity?

These 2 lints specifically are the top two most widely suppressed lints in Clippy. I think it's a reasonable takeaway that Clippy has gotten the default threshold wrong in both cases.

Rendering an html page per lint, with links to docs.rs's code browser, would be sufficient I think.

We can show a few lines as a preview (similar to grep.app) and then link to e.g. https://docs.rs/crate/crossbeam-channel/0.5.1/source/src/err.rs#:~:text=clippy::trivially_copy_pass_by_ref for the full code.