| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Co-authored-by: Guillaume Boisseau <Nadrieril@users.noreply.github.com>
|
|
The lint is unstable, and the lint group `rust_2024_compatibility` must keep working on stable
|
|
Rustfix remains TODO
|
|
|
|
|
|
privacy: Stabilize lint `unnameable_types`
This is the last piece of ["RFC #2145: Type privacy and private-in-public lints"](https://github.com/rust-lang/rust/issues/48054).
Having unstable lints is not very useful because you cannot even dogfood them in the compiler/stdlib in this case (https://github.com/rust-lang/rust/pull/113284).
The worst thing that may happen when a lint is removed are some `removed_lints` warnings, but I haven't heard anyone suggesting removing this specific lint.
This lint is allow-by-default and is supposed to be enabled explicitly.
Some false positives are expected, because sometimes unnameable types are a legitimate pattern.
This lint also have some unnecessary false positives, that can be fixed - see https://github.com/rust-lang/rust/issues/120146 and https://github.com/rust-lang/rust/issues/120149.
Closes https://github.com/rust-lang/rust/issues/48054.
|
|
|
|
|
|
Split refining_impl_trait lint into _reachable, _internal variants
As discussed in https://github.com/rust-lang/rust/issues/119535#issuecomment-1909352040:
> We discussed this today in triage and developed a consensus to:
>
> * Add a separate lint against impls that refine a return type defined with RPITIT even when the trait is not crate public.
> * Place that in a lint group along with the analogous crate public lint.
> * Create an issue to solicit feedback on these lints (or perhaps two separate ones).
> * Have the warnings displayed with each lint reference this issue in a similar manner to how we do that today with the required `Self: '0'` bound on GATs.
> * Make a note to review this feedback on 2-3 release cycles.
This points users to https://github.com/rust-lang/rust/issues/121718 to leave feedback.
|
|
|
|
Fix the conflict problem between the diagnostics fixes of lint `unnecessary_qualification` and `unused_imports`
fixes #121331
For an `item` that triggers lint unnecessary_qualification, if the `use item` which imports this item is also trigger unused import, fixing the two lints at the same time may lead to the problem that the `item` cannot be found.
This PR will avoid reporting lint unnecessary_qualification when conflict occurs.
r? ``@petrochenkov``
|
|
Ungate the `UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES` lint
This was missed during stablisation of the `#[diagnostic]` attribute namespace.
Fixes #122446
|
|
Document how removing a type's field can be bad and what to do instead
Related to #119645
|
|
This was missed during stablisation of the `#[diagnostic]` attribute
namespace.
Fixes #122446
|
|
|
|
|
|
|
|
lint.
|
|
to address issue 121610.
|
|
|
|
Related to #119645
|
|
|
|
Not the dropping of the trailing `s` -- this type describes a single
diagnostic and its name should be singular.
|
|
|
|
r=rustdoc
Made `INVALID_DOC_ATTRIBUTES` lint deny by default
Fixes https://github.com/rust-lang/rust/issues/82730.
# Explanations
The `INVALID_DOC_ATTRIBUTES` lint was marked as "will become a hard error into the future" for quite some time so making it `deny` by default.
<del>Waiting on https://github.com/rust-lang/backtrace-rs/pull/524 for now.</del>
|
|
|
|
|
|
Much better!
Note that this involves renaming (and updating the value of)
`DIAGNOSTIC_BUILDER` in clippy.
|
|
I started by changing it to `DiagData`, but that didn't feel right.
`DiagInner` felt much better.
|
|
|
|
|
|
Warn (or error) when `Self` ctor from outer item is referenced in inner nested item
This implements a warning `SELF_CONSTRUCTOR_FROM_OUTER_ITEM` when a self constructor from an outer impl is referenced in an inner nested item. This is a proper fix mentioned https://github.com/rust-lang/rust/pull/117246#discussion_r1374648388.
This warning is additionally bumped to a hard error when the self type references generic parameters, since it's almost always going to ICE, and is basically *never* correct to do.
This also reverts part of https://github.com/rust-lang/rust/pull/117246, since I believe this is the proper fix and we shouldn't need the helper functions (`opt_param_at`/`opt_type_param`) any longer, since they shouldn't really ever be used in cases where we don't have this problem.
|
|
|
|
Change leak check and suspicious auto trait lint warning messages
The leak check lint message "this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!" is misleading as some cases may not be phased out and could end being accepted. This is under discussion still.
The suspicious auto trait lint the change in behavior already happened, so the new message is probably more accurate.
r? `@lcnr`
Closes #93367
|
|
|
|
Extend Level API
I need this API for https://github.com/rust-lang/rust-clippy/pull/12303: I have a nested `cfg` attribute (so a `MetaItem`) and I'd like to still be able to match against all possible kind of `Level`s.
|
|
|
|
Rename `static_mut_ref` lint to `static_mut_refs`.
|
|
|
|
`swap` has been deprecated in favour of `swap_remove` - the behaviour
is the same though.
|
|
|
|
Invert diagnostic lints.
That is, change `diagnostic_outside_of_impl` and `untranslatable_diagnostic` from `allow` to `deny`, because more than half of the compiler has been converted to use translated diagnostics.
This commit removes more `deny` attributes than it adds `allow` attributes, which proves that this change is warranted.
r? ````@davidtwco````
|
|
That is, change `diagnostic_outside_of_impl` and
`untranslatable_diagnostic` from `allow` to `deny`, because more than
half of the compiler has be converted to use translated diagnostics.
This commit removes more `deny` attributes than it adds `allow`
attributes, which proves that this change is warranted.
|
|
and bless a test I missed
|
|
reports
|
|
|
|
|
|
Make `unsafe_op_in_unsafe_fn` migrated in edition 2024
fixes rust-lang/rust#119823
|
