Skip to content

clippy fixes#146540

Closed
hkBst wants to merge 1 commit intorust-lang:masterfrom
hkBst:clippy-fix-9
Closed

clippy fixes#146540
hkBst wants to merge 1 commit intorust-lang:masterfrom
hkBst:clippy-fix-9

Conversation

@hkBst
Copy link
Copy Markdown
Member

@hkBst hkBst commented Sep 14, 2025

Fixes for clippy::multiple_bound_locations.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 14, 2025
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Sep 14, 2025

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rust-log-analyzer

This comment has been minimized.

where
T: Borrow<Q> + Ord,
Q: Ord,
F: FnOnce(&Q) -> T,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, I'd personally prefer to see us move towards "if we have a where clause, that's the location of all the bounds" -- e.g., in this case the only change would be to move ?Sized to the Q: Ord line. That should also remove most of the changes you've made I think, which seems like a win, and avoids cases where the new PR splits into two (both where-clause bounds and inline bounds in the generic definition).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently the split is local generics are inside the angle brackets with their bounds, and the impl-level generics are bound in the where clause.

But I can change it if you think that would be better...

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general I don't think I think multiple_bound_locations makes much sense to worry over fixing. rustdoc normalizes away the differences and if we really cared about normalizing them in code, IMO that should be a rustfmt (optional?) pass. So I think I'd lean towards silencing this lint in our CI/clippy runs.

Copy link
Copy Markdown
Member Author

@hkBst hkBst Sep 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I hadn't thought of this being rustfmt territory, but that seems like a good idea: rust-lang/rustfmt#6664

@Mark-Simulacrum
Copy link
Copy Markdown
Member

Going to go ahead and close this per the discussion above, feel free to re-open silencing the lint or otherwise changing it.

@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 28, 2025
github-merge-queue Bot pushed a commit to rust-lang/rust-clippy that referenced this pull request Jan 1, 2026
This PR moves the `multiple_bound_locations` lint from `suspicious` to
`style`. The `suspicious` category is described as "code that is most
likely wrong or useless", which is not the case here at all, so `style`
seems more fitting.
Fixes #15736, with some prior discussion at
rust-lang/rust#146540.

changelog: move `multiple_bound_locations` lint to `style` group
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants