Downgrade many_single_char_names to pedantic
As suggested by `@flip1995` in https://github.com/rust-lang/rust-clippy/issues/7666#issuecomment-918993215, by today's standards this lint would be considered `pedantic`.
This is one of the most widely suppressed Clippy lints on crates.io according to https://github.com/dtolnay/noisy-clippy.
In my opinion this lint is just too domain specific for Clippy to have reliable visibility into. Sure there are some cases where the author is just being lazy and could use a kick in the butt, but we're still left with an enormous number of suppressions where single chars are the most appropriate name. For example in the context of colors, a function using `h`, `s`, `l`, `r`, `g`, `b` is 100% sensible and spelling all those out is silly, but it's past the default lint threshold.
---
changelog: Moved [`many_single_char_names`] to `pedantic`
Improve accuracy of `mut_key`
Fixes#6745.
Whilst writing the tests for this, I noticed what I believe is a false negative (the code in `@xFrednet's` [comment](https://github.com/rust-lang/rust-clippy/issues/6745#issuecomment-909658267) doesn't trigger the lint). Currently the tests contain a case for this (which is blatantly ignored), but I'm not at all sure how to implement this (since the lint currently behaves completely differently for ADTs). I'm not sure what should be done - on the one hand the extra test cases are misleading, but on the other hand they don't cause much harm and would save effort for anyone fixing that false negative.
---
changelog: Improve accuracy of `clippy::mutable_key_type`.
Updating issue templates to avoid @rustbot triggers
This adds a space between the ``@`` and the name *rustbot*. This should now surely fix it. If not, I'm giving up.
@ rustbot label +C-bug
---
changelog: none
r? `@camsteffen`
Target directory cleanup
changelog: none
* .cargo/config now has `target-dir` specified so that it is inherited by child projects. The target directory needs to be shared with clippy_dev, but not necessarily at the project root. (cc #7625)
* Uses `std::env::current_exe` (and its parent directories) whenever possible
* `CLIPPY_DRIVER_PATH` and `TARGET_LIBS` are no longer required from rustc bootstrap (but `HOST_LIBS` still is). These can be removed from the rustc side after merging.
* `CLIPPY_DOGFOOD` and the separate target directory are removed. This was originally added to mitigate #7343.
r? `@flip1995`
Fix various redundant_closure bugs
changelog: Fix various false negatives and false positives for [`redundant_closure`]
Closes#3071Closes#4002
This lint is full of weird nuances and this is basically a re-write to tighten up the logic.
Fix result order for `manual_split_once` when `rsplitn` is used
fixes: #7656
changelog: Fix result order for `manual_split_once` when `rsplitn` is used
Backport remerge
This is to keep the backported commit in the repository before force pushing the new beta branch.
r? `@ghost`
changelog: none
(literally none)
Add new lint `iter_not_returning_iterator`
Add new lint [`iter_not_returning_iterator`] to detect method `iter()` or `iter_mut()` returning a type not implementing `Iterator`
changelog: Add new lint [`iter_not_returning_iterator`]
Allow giving reasons for `disallowed_methods`
Fixes#7609.
This permits writing the config for `disallowed-methods` as either a list of strings (like before) or a list of tables, where each table gives the path to the disallowed method and an optional reason for why the method is disallowed.
changelog: Allow giving reasons for [`disallowed_methods`]
`mut_range_bound` check for immediate break after mutation
closes#7532
`mut_range_bound` ignores mutation on range bounds that is placed immediately before break. Still warns if the break is not always reachable.
changelog: [`mut_range_bound`] ignore range bound mutations before immediate break
Avoid slice indexing in Clippy (down with the ICEs)
While working on #7569 I got about 23 lint reports where we can avoid slice indexing by destructing the slice early. This is a preparation PR to avoid fixing them in the lint PR. (The implementation already takes about 300 lines without tests 😅). Either way, this should hopefully be easy to review 🙃
---
changelog: none
Provide `layout_of` automatically (given tcx + param_env + error handling).
After #88337, there's no longer any uses of `LayoutOf` within `rustc_target` itself, so I realized I could move the trait to `rustc_middle::ty::layout` and redesign it a bit.
This is similar to #88338 (and supersedes it), but at no ergonomic loss, since there's no funky `C: LayoutOf<Ty = Ty>` -> `Ty: TyAbiInterface<C>` generic `impl` chain, and each `LayoutOf` still corresponds to one `impl` (of `LayoutOfHelpers`) for the specific context.
After this PR, this is what's needed to get `trait LayoutOf` (with the `layout_of` method) implemented on some context type:
* `TyCtxt`, via `HasTyCtxt`
* `ParamEnv`, via `HasParamEnv`
* a way to transform `LayoutError`s into the desired error type
* an error type of `!` can be paired with having `cx.layout_of(...)` return `TyAndLayout` *without* `Result<...>` around it, such as used by codegen
* this is done through a new `LayoutOfHelpers` trait (and so is specifying the type of `cx.layout_of(...)`)
When going through this path (and not bypassing it with a manual `impl` of `LayoutOf`), the end result is that only the error case can be customized, the query itself and the success paths are guaranteed to be uniform.
(**EDIT**: just noticed that because of the supertrait relationship, you cannot actually implement `LayoutOf` yourself, the blanket `impl` fully covers all possible context types that could ever implement it)
Part of the motivation for this shape of API is that I've been working on querifying `FnAbi::of_*`, and what I want/need to introduce for that looks a lot like the setup in this PR - in particular, it's harder to express the `FnAbi` methods in `rustc_target`, since they're much more tied to `rustc` concepts.
r? `@nagisa` cc `@oli-obk` `@bjorn3`
