- The lint no longer triggers if one of the operands in the boolean
expression comes from a macro expansion.
- Parenthesis are now removed inside the generated block if they are no
longer necessary.
- Error markers have been added.
changelog: [`short_circuit_statement`]: better handling of macros and
better looking suggestions
changelog: none
`x & 15 == 0` is not equivalent to `x.trailing_zeros() > 4`, as `x = 0b10000` is true for
the former and false for the latter.
In fact, clippy itself suggests the following:
```rust
pub fn src(x: i32) -> bool {
x & 15 == 0 // ~error: bit mask could be simplified with a call to `trailing_zeros`
^^^^^^^^^^^ help: try: `x.trailing_zeros() >= 4`
}
```
remove support for the (unstable) #[start] attribute
As explained by `@Noratrieb:`
`#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction.
I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple:
- `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail)
- `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things *anyways*
`#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on ~~Windows~~ wasm, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program.
So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving *any* stability guarantees on), and where there's a pretty easy way to get things working without it in the first place.
Note that this feature has **not** been RFCed in the first place.
*This comment was posted [in May](https://github.com/rust-lang/rust/issues/29633#issuecomment-2088596042) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.*
Closes https://github.com/rust-lang/rust/issues/29633
try-job: x86_64-gnu-nopt
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various
- The lint no longer triggers if the expression comes from macro
expansion
- Parenthesis are now removed inside the generated block if they are no
longer necessary.
This PR fixes an issue with the `significant_drop_in_scrutinee`, where
the lint generates invalid Rust syntax when suggesting fixes for match
expressions that are part of larger expressions, such as in assignment
contexts. For example:
```rust
let mutex = Mutex::new(State {});
let _ = match mutex.lock().unwrap().foo() {
true => 0,
false => 1,
};
```
would suggest:
```rust
let _ = let value = mutex.lock().unwrap().foo();
match value {
```
With this PR, it now suggests:
```rust
let value = mutex.lock().unwrap().foo();
let _ = match value {
```
closes: #13986
changelog: [`significant_drop_in_scrutinee`] Fix incorrect suggestion
for `significant_drop_in_scrutinee` lint in expression context
Without this check, the lint would suggest that
```rust
match test {
true if option == 5 => 10,
_ => 1,
};
```
is replaced by `if test { 10 } else { 1 }`.
This lint detects and removes the unnecessary semicolon after a `match`
or `if` statement returning `()`. It seems to be quite a common
"mistake", given the number of hits (88) we had in the Clippy sources
themselves.
The lint doesn't bother about loops, as `rustfmt` already removes the
extra semicolon. It doesn't handle blocks either, as an extra block
level, followed or not by a semicolon, is likely intentional.
I propose to put the lint in `pedantic`, as putting it in `style` seems
quite hazardous given the number of hits.
Note: there exists a `redundant-semicolon` lint in the compiler, but it
is an early lint and cannot check that the expression evaluates to `()`,
so it ignores the cases we're handling here.
----
changelog: [`unnecessary_semicolon`]: new lint
A multipart suggestion will be used whenever the method call can be
replaced by another one with the first argument removed. It helps place
the new method call in context, especially when it is part of a larger
expression.
This fixes#13995 by applying a suggestion made by @y21.
r? @y21
changelog: [`unnecessary_map_or`]: better representation of suggestions
by placing them in context
This PR changes literal_string_with_formatting_args category from
`suspicious` to `nursery` since there are thousands of false positive on
GitHub.
Closes#13989 since it's no longer problematic with such false positive
with ~~`pedantic`~~ `nursery` category.
changelog: [`literal_string_with_formatting_args` ] change category to
`nursery` from `suspicious`
A multipart suggestion will be used whenever the method call can be
replaced by another one with the first argument removed. It helps place
the new method call in context, especially when it is part of a larger
expression.
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.
