An earlier attempt at this can be found here https://github.com/rust-lang/rust-clippy/pull/7564. This PR still implements two separate lints but I am open to merging them into a single one that's configurable.
bors [Tue, 6 Dec 2022 18:43:28 +0000 (18:43 +0000)]
Auto merge of #9920 - naosense:suppress_lint_in_const, r=xFrednet
add `suppress_restriction_lint_in_const` config
According to #9808 , add a new lint `suppress_lint_in_const` to report even in const context. BTW, i am not good at naming either, if anyone have a better idea, i am happy to change it.
This PR is still in progress, so i keep it draft.
- \[x] Followed [lint naming conventions][lint_naming]
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[x] Executed `cargo dev update_lints`
- \[x] Added lint documentation
- \[x] Run `cargo dev fmt`
changelog: Enhancement: [`indexing_slicing`]: add new config `suppress-restriction-lint-in-const` to enable restriction lints, even if the suggestion might not be applicable
bors [Sun, 4 Dec 2022 01:58:43 +0000 (01:58 +0000)]
Auto merge of #10027 - smoelius:fix-10021, r=dswij
Fix 10021
This PR proposes a fix for #10021.
The problem is similar to the one that `@mikerite` described in #9505. The compiler is generating an empty substitution for a call, even though the type of `Self` seems to be needed for a predicate. In `@mikerite's` case, the call was to [`IntoFuture::into_future`](https://doc.rust-lang.org/std/future/trait.IntoFuture.html#tymethod.into_future). In this case, the call is to [`Try::branch`](https://doc.rust-lang.org/std/ops/trait.Try.html#tymethod.branch).
The proposed fix is to verify that the parameter whose type is changing has an index within the substitution. The strikes me as a reasonable approach, since if the check were to fail, the following code would be a no-op:
bors [Thu, 1 Dec 2022 22:11:01 +0000 (22:11 +0000)]
Auto merge of #9966 - alex-semenyuk:manual_let_else_paren, r=xFrednet
Fix manual_let_else produces a wrong suggestion with or-patterns
Fix #9938
changelog: Sugg: [`manual_let_else`]: Suggestions for or-patterns now include required brackets.
[#9966](https://github.com/rust-lang/rust-clippy/pull/9966)
bors [Wed, 30 Nov 2022 12:44:45 +0000 (12:44 +0000)]
Auto merge of #9989 - xFrednet:9986-move-safety-thingy, r=flip1995
Move `unnecessary_unsafety_doc` to `pedantic`
This lint was added in #9822. I like the idea, but also agree with #9986 as well. I think it should at least not be warn-by-default. This is one of these cases, where I'd like a group between pedantic and restriction. But I believe that users using `#![warn(clippy::pedantic)]` will know how to enable the lint if they disagree with it.
---
Since the lint is new:
changelog: none
r? `@flip1995` since I'd suggest back porting this, the original PR was merged 16 days ago.
Closes: #9986 (While it doesn't address everything, I believe that this is the best compromise)
bors [Wed, 30 Nov 2022 11:13:09 +0000 (11:13 +0000)]
Auto merge of #104905 - compiler-errors:normalization-changes, r=spastorino
Some initial normalization method changes
1. Rename `AtExt::normalize` to `QueryNormalizeExt::query_normalize` (using the `QueryNormalizer`)
2. Introduce `NormalizeExt::normalize` to replace `partially_normalize_associated_types_in` (using the `AssocTypeNormalizer`)
3. Rename `FnCtxt::normalize_associated_types_in` to `FnCtxt::normalize`
4. Remove some unused other normalization fns in `Inherited` and `FnCtxt`
Also includes one drive-by where we're no longer creating a `FnCtxt` inside of `check_fn`, but passing it in. This means we don't need such weird `FnCtxt` construction logic.
bors [Tue, 29 Nov 2022 11:16:01 +0000 (11:16 +0000)]
Auto merge of #9975 - xFrednet:0000-refutable-slice-pedantic, r=llogiq
Move `index_refutable_slice` to `pedantic`
During the creation, I out this lint into the nursery group to let it run in the wild before moving it to a commonly used group. This move never happened until now, though. It should be safe, as Clippy and I have been using it for months and there are no open issues for is :)
---
changelog: Move `index_refutable_slice` to `pedantic` (Now warn-by-default)
[#9975](https://github.com/rust-lang/rust-clippy/pull/9975)
bors [Mon, 28 Nov 2022 17:22:36 +0000 (17:22 +0000)]
Auto merge of #9865 - nyurik:allow-mixed, r=xFrednet
Add allow-mixed-uninlined-format-args config
Implement `allow-mixed-uninlined-format-args` config param to change the behavior of the `uninlined_format_args` lint. Now it is a part of `style` per [Zulip chat](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/.60uninlined_format_args.60.20category), and won't propose inlining in case of a mixed usage, e.g. `print!("{} {}", var, 1+2)`. If the user sets `allow-mixed-uninlined-format-args` config param to `false`, the lint would behave like it did before -- proposing to inline args even in the mixed case.
---
changelog: [`uninlined_format_args`]: Added a new config `allow-mixed-uninlined-format-args` to allow the lint, if only some arguments can be inlined
[#9865](https://github.com/rust-lang/rust-clippy/pull/9865)
changelog: Moved [`uninlined_format_args`] to `style` (Now warn-by-default)
[#9865](https://github.com/rust-lang/rust-clippy/pull/9865)
Yuri Astrakhan [Sun, 27 Nov 2022 15:12:51 +0000 (10:12 -0500)]
Add allow-mixed-uninlined-format-args config
Implement `allow-mixed-uninlined-format-args` config param to change the behavior of the `uninlined_format_args` lint. Now it is a part of `style`, and won't propose inlining in case of a mixed usage, e.g. `print!("{} {}", var, 1+2)`. If the user sets allow-mixed-uninlined-format-args config param to `false`, then it would behave like before, proposing to inline args even in the mixed case.
projects / rust.git / log