Skip to content

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
wants to merge 36 commits into
base: master
Choose a base branch
from
Open

Conversation

flip1995
Copy link
Member

@flip1995 flip1995 commented May 1, 2025

samueltardieu and others added 30 commits April 8, 2025 18:16
`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
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
The Miri Cronjob Bot and others added 6 commits April 29, 2025 06:23
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
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 1, 2025
@rustbot
Copy link
Collaborator

rustbot commented May 1, 2025

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@Manishearth
Copy link
Member

@bors r+ p=1 rollup=never

@bors
Copy link
Collaborator

bors commented May 1, 2025

📌 Commit c9992d6 has been approved by Manishearth

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 1, 2025
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.