Add `repeated_where_clause_or_trait_bound` lint
I thought I would try and scratch my own itch for #8674.
1. Is comparing the `Res` the correct way for ensuring we have the same trait?
2. Is there a way to get the spans for the bounds and clauses for suggestions?
I tried to use `GenericParam::bounds_span_for_suggestions` but it only gave me an empty span at the end of the spans.
I tried `WhereClause::span_for_predicates_or_empty_place` and it included the comma.
3. Is there a simpler way to get the trait names? I have used the spans of the traits because I didn't see a way to get it off the `Res` or `Def`.
changelog: Add ``[`repeated_where_clause_or_trait_bound`]`` lint.
Rollup of 6 pull requests
Successful merges:
- #98622 (rustc_target: Flip the default for `TargetOptions::executables` to true)
- #98633 (Fix last `let_chains` blocker)
- #98972 (Suggest adding a missing zero to a floating point number)
- #99038 (Some more `EarlyBinder` cleanups)
- #99154 (use PlaceRef::iter_projections to fix old FIXME)
- #99171 (Put back UI test regex)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Put back UI test regex
I just realized I overwrote these two commits in https://github.com/rust-lang/rust/pull/99055 when force pushing to fix the stdout output...
r? `@Dylan-DPC`
Fix last `let_chains` blocker
In order to forbid things like `let x = (let y = 1);` or `if let a = 1 && { let x = let y = 1; } {}`, the parser **HAS** to know the context of `let`.
This context thing is not a surprise in the parser because you can see **a lot** of ad hoc fixes mixing parsing logic with validation logic creating code that looks more like spaghetti with tomato sauce.
To make things even greater, a new ad hoc fix was added to only allow `let`s in a valid `let_chains` context by checking the previously processed token. This was the only solution I could think of and believe me, I thought about it for a long time 👍
In the long term, it should be preferable to segregate different responsibilities or create a more robust and cleaner parser framework.
cc https://github.com/rust-lang/rust/pull/94927
cc https://github.com/rust-lang/rust/issues/53667
change applicability type to MaybeIncorrect in `explicit_counter_loop`
close#9013
This PR changes applicability type to `MaybeIncorrect`, because the suggestion is not `MachineApplicable`.
changelog: change applicability type to MaybeIncorrect in `explicit_counter_loop`
Moves our projection handling code into a common file, and avoids the use of a
general mplace-based fallback function by have more specialized implementations.
mplace_index (and the other slice-related functions) could be more efficient by
copy-pasting the body of operand_index. Or we could do some trait magic to share
the code between them. But for now this is probably fine.
Fixes for `branches_sharing_code`
fixes#7198fixes#7452fixes#7555fixes#7589
changelog: Don't suggest moving modifications to locals used in any of the condition expressions in `branches_sharing_code`
changelog: Don't suggest moving anything after a local with a significant drop in `branches_sharing_code`
Rollup of 8 pull requests
Successful merges:
- #97210 (Support `-A`, `-W`, `-D` and `-F` when running `./x.py clippy`)
- #99055 (Fix rustdoc help options)
- #99075 (Fix duplicated type annotation suggestion)
- #99124 (Fix sized check ICE in asm check)
- #99142 (fix(doctest): treat fatal parse errors as incomplete attributes)
- #99145 (Don't rerun the build script for the compiler each time on non-windows platforms)
- #99146 (Do not error during method probe on `Sized` predicates for types that aren't the method receiver)
- #99161 (compiletest: trim edition before passing as flag)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
