| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
|
|
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
|
|
|
|
|
|
Disallow reference to `static mut` and adding `static_mut_ref` lint
Closes #114447
r? `@scottmcm`
|
|
|
|
Add `E0796` error code.
Add `static_mut_ref` lint.
This is the idea for the 2024 edition.
|
|
Replace a number of FxHashMaps/Sets with stable-iteration-order alternatives
This PR replaces almost all of the remaining `FxHashMap`s in query results with either `FxIndexMap` or `UnordMap`. The only case that is missing is the `EffectiveVisibilities` struct which turned out to not be straightforward to transform. Once that is done too, we can remove the `HashStable` implementation from `HashMap`.
The first commit adds the `StableCompare` trait which is a companion trait to `StableOrd`. Some types like `Symbol` can be compared in a cross-session stable way, but their `Ord` implementation is not stable. In such cases, a `StableCompare` implementation can be provided to offer a lightweight way for stable sorting. The more heavyweight option is to sort via `ToStableHashKey`, but then sorting needs to have access to a stable hashing context and `ToStableHashKey` can also be expensive as in the case of `Symbol` where it has to allocate a `String`.
The rest of the commits are rather mechanical and don't overlap, so they are best reviewed individually.
Part of [MCP 533](https://github.com/rust-lang/compiler-team/issues/533).
|
|
Merge `unused_tuple_struct_fields` into `dead_code`
This implicitly upgrades the lint from `allow` to `warn` and places it into the `unused` lint group.
[Discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Moving.20.60unused_tuple_struct_fields.60.20from.20allow.20to.20warn)
|
|
StableCompare is a companion trait to `StableOrd`. Some types like `Symbol` can be compared in a cross-session stable way, but their `Ord` implementation is not stable. In such cases, a `StableOrd` implementation can be provided to offer a lightweight way for stable sorting. (The more heavyweight option is to sort via `ToStableHashKey`, but then sorting needs to have access to a stable hashing context and `ToStableHashKey` can also be expensive as in the case of `Symbol` where it has to allocate a `String`.)
|
|
This implicitly upgrades the lint from `allow` to `warn` and places it
into the `unused` lint group.
|
|
|
|
make soft_unstable show up in future breakage reports
If we want to break these in the future, let's warn users of affected crates.
|
|
|
|
|
|
Clarify how to choose a FutureIncompatibilityReason variant.
There has been some confusion about how to choose these variants, or what the procedure is for handling future-incompatible errors. Hopefully this helps provide some more information on how these work.
|
|
compile-time evaluation: detect writes through immutable pointers
This has two motivations:
- it unblocks https://github.com/rust-lang/rust/pull/116745 (and therefore takes a big step towards `const_mut_refs` stabilization), because we can now detect if the memory that we find in `const` can be interned as "immutable"
- it would detect the UB that was uncovered in https://github.com/rust-lang/rust/pull/117905, which was caused by accidental stabilization of `copy` functions in `const` that can only be called with UB
When UB is detected, we emit a future-compat warn-by-default lint. This is not a breaking change, so completely in line with [the const-UB RFC](https://rust-lang.github.io/rfcs/3016-const-ub.html), meaning we don't need t-lang FCP here. I made the lint immediately show up for dependencies since it is nearly impossible to even trigger this lint without `const_mut_refs` -- the accidentally stabilized `copy` functions are the only way this can happen, so the crates that popped up in #117905 are the only causes of such UB (in the code that crater covers), and the three cases of UB that we know about have all been fixed in their respective crates already.
The way this is implemented is by making use of the fact that our interpreter is already generic over the notion of provenance. For CTFE we now use the new `CtfeProvenance` type which is conceptually an `AllocId` plus a boolean `immutable` flag (but packed for a more efficient representation). This means we can mark a pointer as immutable when it is created as a shared reference. The flag will be propagated to all pointers derived from this one. We can then check the immutable flag on each write to reject writes through immutable pointers.
I just hope perf works out.
|
|
pointer occurs
|
|
|
