1.83 stabilized `CONST_MUT_REFS`, also allowing for `const fn` to mutate
through mutable references. This ensures `missing_const_for_fn` is
emitted for those cases.
changelog: [`missing_const_for_fn`]: Now suggests marking some functions
taking mutable references `const`
By assuming that a recursive type is normalizable within the deeper
calls to `is_normalizable_helper()`, more cases can be handled by this
function.
In order to fix stack overflows, a recursion limit has also been added
for recursive generic type instantiations.
Counting in bytes for a pointer to `u8` is legitimate and must not
trigger the lint. Also, this prevents linting the
`{std,core}::ptr::write_bytes` as it manipulates bytes.
Proposing to replace
```rust
let mut x = PathBuf::from("/foo");
x.push("/bar");
```
by
```rust
let mut x = PathBuf::from("/foo");
x.push("bar");
```
changes the content of `x` (`/bar` ⇒ `/foo/bar`).
Using `Vec::extend(std::iter::repeat_n(item, N))` allows to use the more
natural number of elements to add `N`, as is probably done in the original
loop, instead of computing the difference between the existing number of
elements and the wanted one.
Before MSRV 1.82, the older suggestion to use `Vec::resize()` is still
issued.
I'll take a short break from auto assignments. My last few weeks have
been busy and I feel like getting my inbox back in order and taking a
short breather will be the best for me.
I still plan to review the PRs I'm currently assigned to and writing the
changelogs.
Jup that's it, have a good day, who ever is reading this =^.^=
changelog: none
deprecate `std::intrinsics::transmute` etc, use `std::mem::*` instead
The `rustc_allowed_through_unstable_modules` attribute lets users call `std::mem::transmute` as `std::intrinsics::transmute`. The former is a reexport of the latter, and for a long time we didn't properly check stability for reexports, so making this a hard error now would be a breaking change for little gain. But at the same time, `std::intrinsics::transmute` is not the intended path for this function, so I think it is a good idea to show a deprecation warning when that path is used. This PR implements that, for all the functions in `std::intrinsics` that carry the attribute.
I assume this will need ``@rust-lang/libs-api`` FCP.
Treat safe target_feature functions as unsafe by default [less invasive variant]
This unblocks
* #134090
As I stated in https://github.com/rust-lang/rust/pull/134090#issuecomment-2541332415 I think the previous impl was too easy to get wrong, as by default it treated safe target feature functions as safe and had to add additional checks for when they weren't. Now the logic is inverted. By default they are unsafe and you have to explicitly handle safe target feature functions.
This is the less (imo) invasive variant of #134317, as it doesn't require changing the Safety enum, so it only affects FnDefs and nothing else, as it should.
changelog: [`useless-nonzero-new_unchecked`]: new lint
Close#13991
### What it does
Checks for `NonZero*::new_unchecked(<literal>)` being used in a `const`
context.
### Why is this bad?
Using `NonZero*::new_unchecked()` is an `unsafe` function and requires
an `unsafe` context. When used with an
integer literal in a `const` context, `NonZero*::new().unwrap()` will
provide the same result with identical
runtime performances while not requiring `unsafe`.
### Example
```no_run
const PLAYERS: NonZeroUsize = unsafe { NonZeroUsize::new_unchecked(3) };
```
Use instead:
```no_run
const PLAYERS: NonZeroUsize = NonZeroUsize::new(3).unwrap();
```
Commit 9ef6e2199c introduced a check to
ensure that Clippy doesn't consider a lifetime present in an explicit
self types as being the default for an elided output lifetime. For
example, elision did not work in the case like:
```rust
fn func(self: &Rc<Self>, &str) -> &str { … }
```
Since Rust 1.81.0, the lifetime in the self type is now considered the
default for elision. Elision should then be suggested when appropriate.
changelog: [`needless_lifetimes`]: suggest elision of lifetimes present
in explicit self types as well
r? @Alexendoo
because of #8278
Temporaries created inside the expansion of `.await` will be dropped and
need no checking. Looking inside the expansion will trigger false
positives.
changelog: [`significant_drop_in_scrutinee`]: do not falsely warn for
temporaries created by `.await` expansion
Fix#13927
Commit 9ef6e2199c introduced a check to
ensure that Clippy doesn't consider a lifetime present in an explicit
self type as being the default for an elided output lifetime. For
example, elision did not work in the case like:
```rust
fn func(self: &Rc<Self>, &str) -> &str { … }
```
Since Rust 1.81.0, the lifetime in the self type is now considered
the default for elision. Elision should then be suggested when
appropriate.
changelog: [`slow_vector_initialization`]: auto-fix when appropriate
I made a change for `slow_vector_initialization` lint suggestion to use
`vec!` with size and remove the unneeded `resize` (or similar one) call
in #13912, while only the former one was suggested in the previous
implementation. Now, I think this lint can be automatically fixed with
no unnecessary code in some cases. I wrote “in some cases” because if
there are comments between vector declaration and `resize`, Clippy
shouldn't apply auto-fix because the comment may informational.
Some widely used crates, such as `pin-project-lite`, make use of a
`pub(crate)` construct in a private module inside a public macro. This
makes unrelated project trigger the lint.
There is also an unfortunate situation for Clippy itself: when a new
version of `pin-project-lite` or similar lint-trigerring crates is
released, those lints which can be found in hundreds of occurrences in
dependent crates will change, and appear as diffs in unrelated Clippy PR
because the base lintcheck run will be cached with the ancient release
of the crates. We currently have the situation
[here](https://github.com/rust-lang/rust-clippy/actions/runs/12635410895?pr=13851#user-content-redundant-pub-crate-removed),
which 219 lints removed and 219 lints added because of a
`pin-project-lite` version change between runs, and the fact that
`redundant_pub_crate` triggers on external macros.
Also:
- Fix#10636
- Fix#12213
changelog: [`redundant_pub_crate`]: do not trigger on external macros
