-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Clippy subtree update #140540
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
Open
flip1995
wants to merge
36
commits into
rust-lang:master
Choose a base branch
from
flip1995:clippy-subtree-update
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Clippy subtree update #140540
+1,819
−582
Conversation
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
`ptr_eq` was recently enhanced to lint on more cases of raw pointers comparison: - lint on all raw pointer comparison, by proposing to use `[core|std]::ptr::eq(lhs, rhs)` instead of `lhs == rhs`; - removing one symetric `as usize` on each size if needed - peeling any level of `as *[const|mut] _` if the remaining expression can still be coerced into the original one (i.e., is a ref or raw pointer to the same type as before) The current change restricts the lint to the cases where at least one level of symetric `as usize`, or any conversion to a raw pointer, could be removed. For example, a direct comparaison of two raw pointers will not trigger the lint anymore.
`ptr_eq` was recently enhanced to lint on more cases of raw pointers comparison: - lint on all raw pointer comparison, by proposing to use `[core|std]::ptr::eq(lhs, rhs)` instead of `lhs == rhs`; - removing one symetric `as usize` on each size if needed - peeling any level of `as *[const|mut] _` if the remaining expression can still be coerced into the original one (i.e., is a ref or raw pointer to the same type as before) The current change restricts the lint to the cases where at least one level of symetric `as usize`, or any conversion to a raw pointer, could be removed. For example, a direct comparaison of two raw pointers will not trigger the lint anymore. changelog: [`ptr_eq`]: do not lint when comparing two raw pointers directly with no casts involved Fixes rust-lang/rust-clippy#14525
it was added back in 6035e05, at which time there were some files matching it, e.g. https://github.com/rust-lang/rust-clippy/blob/6035e050e83cc991f94797eef4d720c0b61d8955/clippy_lints/src/lib.deprecated.rs
it was added back in 6035e05, at which time there were some files matching it, e.g. https://github.com/rust-lang/rust-clippy/blob/6035e050e83cc991f94797eef4d720c0b61d8955/clippy_lints/src/lib.deprecated.rs fixes rust-lang/rust-clippy#14670 changelog: none
Fixes rust-lang/rust-clippy#14675 by making it clearer that the constructor needs to be removed as well Also fixes rust-lang/rust-clippy#8392 changelog: none
`cargo dev fmt` seems to not work for some reason (possibly because of all the comments in the let-chain), so I formatted it manually -- I hope it's right changelog: none
Matches the `rustc` terminology changelog: none
…ang#14643) Closes rust-lang/rust-clippy#14640 changelog: [`unnecessary_cast`] fix extra brackets in suggestions when in macro
…st-lang#14504) Closes rust-lang#8710 changelog: [`equatable_if_let`] fix wrong suggestions when involving reference
…14666) here is my small fix changelog: fix suggestion span to avoid showing macro name in `.div_ceil()` suggestion i changed this line `let divisor_snippet = snippet_with_applicability(cx, rhs.spansource_callsite(), "..", applicability);` to this line `let divisor_snippet = snippet_with_applicability(cx, rhs.span, "..", applicability);` to fix problem where this warning in macro expands like this ```rust 4 | let _ = (x + 7) / 8; | ^^^^^^^^^^^ help: consider using `.div_ceil()`: `x.div_ceil(y!())` ``` [play it yourself](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=397aa8cd2ffffb24a286fbddbc75446c) as you can see here it looks like `x.div_ceil(y!())` and contains macro signature so i fixed this problem, i will look closely if there any more problems like this and fix them in order **Related issue** fixes [rust-lang/rust-clippy#14665](rust-lang/rust-clippy#14665)
Follow up to rust-lang/rust-clippy#14650 Replaces uses in the form `s.as_str() == "literal"` r? @y21 changelog: none
…st-lang#14609) Closes rust-lang/rust-clippy#14577. Migrate this lint to late pass and avoids `unit_never_type_fallback` since it is no longer permitted in Rust 2024. changelog: [`unused_unit`] fix wrong suggestions when unit never type fallback
…ogy, r=oli-obk Remove `weak` alias terminology I find the "weak" alias terminology to be quite confusing. It implies the existence of "strong" aliases (which do not exist) and I'm not really sure what about weak aliases is "weak". I much prefer "free alias" as the term. I think it's much more obvious what it means as "free function" is a well defined term that already exists in rust. It's also a little confusing given "weak alias" is already a term in linker/codegen spaces which are part of the compiler too. Though I'm not particularly worried about that as it's usually very obvious if you're talking about the type system or not lol. I'm also currently trying to write documentation about aliases and it's somewhat awkward/confusing to be talking about *weak* aliases, when I'm not really sure what the basis for that as the term actually *is*. I would also be happy to just find out there's a nice meaning behind calling them "weak" aliases :-) r? `@oli-obk` maybe we want a types MCP to decide on a specific naming here? or maybe we think its just too late to go back on this naming decision ^^'
Closes rust-lang/rust-clippy#14677 changelog: [`zombie_processes`] fix FP inside closures
implement or-patterns for pattern types These are necessary to represent `NonZeroI32`, as the range for that is `..0 | 1..`. The `rustc_scalar_layout_range_*` attributes avoided this by just implementing wraparound and having a single `1..=-1` range effectively. See https://rust-lang.zulipchat.com/#narrow/channel/481660-t-lang.2Fpattern-types/topic/.60or.20pattern.60.20representation.20in.20type.20system/with/504217694 for some background discussion cc rust-lang#123646 r? `@BoxyUwU`
r? @ghost changelog: none
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
@bors r+ p=1 rollup=never |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
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