Closed
Conversation
When a user explicitly tags a param as unused (yet?), there is no need to raise another lint on it.
…times, r=cjgillot Fix `elided_named_lifetimes` in code rust-lang#129207 (comment) r? cjgillot
…ng_sub_expression, r=xFrednet Diverging subexpression lint should not fire on todo!() As per rust-lang#10243 it is not that helpful to point out that a subexpression diverges, so do not fire on todo changelog: [`diverging_sub_expression`]: do not trigger on todo
Clippy subtree update r? `@Manishearth`
…blyxyas Ignore underscore-prefixed args for needless_pass_by_value lint When a user explicitly tags a param as unused (yet?), there is no need to raise another lint on it. fixes rust-lang#7295 Note that I had to rename all `_*` params in the tests, but kept the variable name length to avoid extra changes in the expected output. changelog: [`needless_pass_by_value`]: do not warn if the argument name starts with an `_`
…=dswij
Rewrite `empty_line_after_doc_comments` and `empty_line_after_outer_attr`, move them from `nursery` to `suspicious`
changelog: [`empty_line_after_doc_comments`], [`empty_line_after_outer_attr`]: rewrite and move them from `nursery` to `suspicious`
They now lint when there's a comment between the last attr/doc comment and the empty line, to cover the case:
```rust
/// Docs for `old_code
// fn old_code() {}
fn new_code() {}
```
When these lints or `suspicious_doc_comments` trigger we no longer trigger any other doc lint as a broad fix for rust-lang#12917, reverts some of rust-lang#13002 as the empty line lints cover it
I ended up not doing rust-lang/rust-clippy#12917 (comment) as I don't think it's needed
check std::panic::panic_any in panic lint close rust-lang#13292 This PR detects `std::panic::panic_any` in panic lint. changelog: check std::panic::panic_any in panic lint
…ns, r=Manishearth Fix manual_range_patterns case with one element at OR Close rust-lang#11825 As mentioned rust-lang#11825 `OR` can be used for stylistic purposes with one element, we can filter this case from triggering lint changelog: [`manual_range_patterns`]: not trigger when `OR` has only one element
…e_items, r=llogiq Add new lint: `used_underscore_items` Closes rust-lang#13260 --- changelog: new [`used_underscore_items`] lint against using items with a single leading underscore
new lint: `zombie_processes` Closes rust-lang#10754 Lint description should explain this PR, so I think there's nothing else to say here ^^ changelog: new lint: [`zombie_processes`]
Use `is_diagnostic_item` for checking a def_id in `unnecessary_min_or_max`. close rust-lang#13191 This PR fixes the false positives in `unnecessary_min_or_max `. We should use `is_diagnostic_item` for checking def_ids in this lint. ---- changelog: fix false positive in `unnecessary_min_or_max `.
…ature, r=flip1995 Remove `feature=cargo-clippy` argument Roses are red, Violets are blue, Fixme was written, And now it's due --- changelog: **Important Change** Removed the implicit `cargo-clippy` feature set by Clippy as announced here: <https://blog.rust-lang.org/2024/02/28/Clippy-deprecating-feature-cargo-clippy.html> [rust-lang#13246](rust-lang/rust-clippy#13246) Follow-up of: rust-lang/rust-clippy#12292 r? `@flip1995` cc: `@GuillaumeGomez`
…e`, it will not break clippy
…check, r=y21 Extend `implicit_saturating_sub` lint Fixes rust-lang#10070. It can serve as base if we want to add equivalent checks for other arithmetic operations. Also one important note: when writing this lint, I realized that I could check for wrong conditions performed beforehand on subtraction and added another part in the lint. Considering they both rely on the same checks, I kept both in the same place. Not sure if it makes sense though... changelog: Extend `implicit_saturating_sub` lint
…gillot Lint that warns when an elided lifetime ends up being a named lifetime As suggested in rust-lang#48686 (comment) Fixes rust-lang#48686
…oc_fix, r=y21 Provide more clear example for `WRONG_SELF_CONVENTION` Provide more clear example for `WRONG_SELF_CONVENTION` changelog: none
Add new check for passing pointers to an `asm!` block with `nomem` option changelog: Add new check for passing pointers to an `asm!` block with `nomem` option Continuing work from rust-lang#127063
…tri3 move `manual_c_str_literals` to complexity IMO the suggestion to use `c""` literals over a hardcoded `\0` byte string literal has some fairly strong upsides (no need to manually null-terminate it and the compiler checks for intermediary null bytes) that this should just be enabled by default. It's also written slightly conservatively to only emit a warning when we can be reasonably confident that the lint is *actually* applicable (that is, lint on e.g. `b"foo\0".as_ptr()` but not `b"foo\0"`. The latter looks like a c-string but its type is `&[u8; _]`, and if it's used in a context where a byte slice is needed then you have no nice way to convert to it from a `c"foo"` literal of type `&CStr`). changelog: move [`manual_c_str_literals`] to complexity (now warn-by-default)
Minor code simplification changelog: none
…lip1995 Bump actions/download-artifact from 3 to 4 r? `@ghost` changelog: none
Changelog for Clippy 1.81 🔰 Roses are red, Violets are blue, Expectations are stable, And reasons are set --- ### The cat of this release is *Keepy* submitted by `@blyxyas:` <img height=500 src="https://github.com/rust-lang/rust-clippy/assets/73757586/902dd802-5ac8-471e-bb93-e195526ba580" alt="The cats of this Clippy release" /> Cats for the next release can be nominated in the comments :D --- changelog: none
Rustup r? `@ghost` changelog: none
rustbot
added
the
S-waiting-on-review
Collaborator
|
Some changes occurred in src/tools/clippy cc @rust-lang/clippy These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Member
|
CI broken |
flip1995
commented
Sep 5, 2024
Comment on lines
+231
to
+236
| diag.multipart_suggestion_with_style( | ||
| format!("if the empty {lines} {are} unintentional remove {them}"), | ||
| empty_lines().map(|empty_line| (empty_line, String::new())).collect(), | ||
| Applicability::MaybeIncorrect, | ||
| SuggestionStyle::HideCodeAlways, | ||
| ); |
Member
Author
There was a problem hiding this comment.
This triggers the debug assertion that in a multipart suggestion, one part can't be and empty span and at the same time suggest to remove it.
I think a possible fix would be to change this code to a span_suggestion and build a span from first_gap.prev_stop.span.hi to empty_lines().last().hi or something like that. I tried it, but ran into off-by-one errors...
@Alexendoo do you have time to take a look at this? You can reproduce locally by setting debug-assertions = true in [rust] in the config.toml.
Member
Author
There was a problem hiding this comment.
@estebank What is the best way to suggest removing non contiguous empty lines. I.e.
1 /// Comment that should stay
2
3 // More things that should stay
4
5 struct X;The empty_lines() functions returns the spans of lines 2 and 4 which should be removed, but their spans are 2:1-2:1 and 4:1-4:1, so considered empty spans. rustfix has no problem applying this suggestion, while the debug_assertion causes the failure in CI. Is there a better way to suggest removing those empty lines, than the above? If not, should the debug_assertion in the multipart_suggestion implementation be relaxed?
Member
There was a problem hiding this comment.
If the suggestion is to remove a line, shouldn't the spans be 2:1-3:1 and 4:1-5:1? An empty span wouldn't include the newline character at 2:1, would it? 🤔
I'm surprised rustfix can fix it with no problem
Member
Author
There was a problem hiding this comment.
I tried adding a BytePos(1) to the span. But then the spans overlap (for 2 contiguous empty lines), as the first span is 2:1-3:1 and the next span is 3:1-4:1 with an overlap at 3:1. And rustfix can't apply multipart suggestions with overlapping spans.
Member
Author
There was a problem hiding this comment.
Will be fixed in rust-lang/rust-clippy#13439
Since we already behind the sync after this one by 3 days, I will open a new PR for it.
Collaborator
|
☔ The latest upstream changes (presumably #130572) made this pull request unmergeable. Please resolve the merge conflicts. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
r? @Manishearth
Cargo.lock update due to Clippy version bump.