[stable] 1.72.1 release
This backports:
* Remove assert that checks type equality #115215
* implied bounds: do not ICE on unconstrained region vars #115559
* rustdoc: correctly deal with self ty params when eliding default object lifetimes #115276
* Stop emitting non-power-of-two vectors in (non-portable-SIMD) codegen #115236
* Normalize before checking if local is freeze in deduced_param_attrs #114948
Some cherry-picks required merge conflict resolution, we'll see if I got it right based on CI (rustdoc fix and LLVM codegen test).
r? `@Mark-Simulacrum`
Disable MIR SROA optimization by default
Turn off the MIR SROA optimization by default to prevent incorrect debuginfo generation and rustc ICEs caused by invalid LLVM IR being created.
Related to #115113
r? `@cuviper`
cc `@saethlin`
Turn off the MIR SROA optimization by default to prevent incorrect
debuginfo generation and rustc ICEs caused by invalid LLVM IR being
created.
Related to #115113
This was not the correct fix. The problem was two-fold:
- `download-rustc` didn't respect `llvm.assertions`
- `rust-dev` was missing a bump to `download-ci-llvm-stamp`
The first is fixed in this PR and the latter was fixed a while ago. Revert this change to avoid breaking `rpath = false`.
`Ok(0)` is indeed something the caller may interpret as an error, but
that's the *correct* thing to return if the writer can't accept any more
bytes.
(cherry picked from commit 5210f482d7309004c0ff3f6306f052f8d5adb67b)
[`missing_fields_in_debug`]: make sure self type is an adt
Fixes#11063, another ICE that can only happen in core.
This lint needs the `DefId` of the implementor to get its fields, but that ICEs if the implementor does not have a `DefId` (as is the case with primitive types, e.g. `impl Debug for bool`), which is where this ICE comes from.
This PR changes the check I added in #10897 to be more... robust against `Debug` implementations we don't want to lint.
Instead of just checking if the self type is a type parameter and "special casing" one specific case we don't want to lint, we should probably rather just check that the self type is either a struct, an enum or a union and only then continue.
That prevents weird edge cases like this one that can only happen in core.
Again, I don't know if it's even possible to add a test case for this since one cannot implement `Debug` for primitive types outside of the crate that defined `Debug` (core).
I did make sure that this PR no longer ICEs on `impl<T> Debug for T` and `impl Debug for bool`.
Maybe writing such a test is possible with `#![no_core]` and then re-defining the `Debug` trait or something like that...?
changelog: [`missing_fields_in_debug`]: make sure self type is an adt (fixes an ICE in core)
r? `@Alexendoo` (reviewed the last PRs for this lint)
[`useless_conversion`]: only lint on paths to fn items and fix FP in macro
Fixes#11065 (which is actually two issues: an ICE and a false positive)
It now makes sure that the function call path points to a function-like item (and not e.g. a `const` like in the linked issue), so that calling `TyCtxt::fn_sig` later in the lint does not ICE (fixes https://github.com/rust-lang/rust-clippy/issues/11065#issuecomment-1616836099).
It *also* makes sure that the expression is not part of a macro call (fixes https://github.com/rust-lang/rust-clippy/issues/11065#issuecomment-1616919639). ~~I'm not sure if there's a better way to check this other than to walk the parent expr chain and see if any of them are expansions.~~ (edit: it doesn't do this anymore)
changelog: [`useless_conversion`]: fix ICE when call receiver is a non-fn item
changelog: [`useless_conversion`]: don't lint if argument is a macro argument (fixes a FP)
r? `@llogiq` (reviewed #10814, which introduced these issues)
[`unnecessary_literal_unwrap`]: Fix ICE on None.unwrap_or_default()
Fixes#11099Fixes#11064
I'm running into #11099 (cc `@y21)` on my Rust codebase. Clippy ICEs on this code when evaluating the `unnecessary_literal_unwrap` lint:
```rust
fn main() {
let val1: u8 = None.unwrap_or_default();
}
```
This fixes that ICE and adds an message specifically for that case:
```
error: used `unwrap_or_default()` on `None` value
--> $DIR/unnecessary_literal_unwrap.rs:26:5
|
LL | None::<String>.unwrap_or_default();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the `None` and `unwrap_or_default()`: `String::default()`
```
This PR also fixes the same ICE with `None.unwrap_or_else` (by giving the generic error message for the lint in that case).
changelog: Fix ICE in `unnecessary_literal_unwrap` on `None.unwrap_or_default()`
redundant_type_annotations: only pass certain def kinds to type_of
Fixes#11190Fixesrust-lang/rust#113516
Also adds an `is_lint_allowed` check to skip the lint when it's not needed
changelog: none
[`arc_with_non_send_sync`]: don't lint if type has nested type parameters
Fixes#11076
changelog: [`arc_with_non_send_sync`]: don't lint if type has nested type parameters
r? `@Manishearth`
[beta] Update LLVM to resolve a miscompilation found in 114312.
Related issue: #114312 .
After the master updates the LLVM, we will add the same test cases. In the meantime, close the issue.
fix to test as proposed by wesleywiser
Co-authored-by: Wesley Wiser <wwiser@gmail.com>
(cherry picked from commit 5881e5f88d9245ef9259ca600b32af80d5972a7f)
Rust requires a previous version of Rust to build, such as the current version, or the
previous version. However, the version comparison logic did not take patch releases
into consideration when doing the version comparison for the current branch, e.g.
Rust 1.71.1 could not be built by Rust 1.71.0 because it is neither an exact version
match, or the previous version.
Adjust the version comparison logic to tolerate mismatches in the patch version.
Signed-off-by: Ariadne Conill <ariadne@dereferenced.org>
(cherry picked from commit 31a81a08786826cc6e832bd0b49fb8b934e29648)
Now that this lint runs on any external-ABI fn-ptr, normalization won't
always succeed, so use `try_normalize_erasing_regions` instead.
Signed-off-by: David Wood <david@davidtw.co>
(cherry picked from commit 09434a2575cee12b241c516ad91f21d4b4f9c3fd)
Consider `()` within types to be FFI-safe, and `()` to be FFI-safe as a
return type (incl. when in a transparent newtype).
Signed-off-by: David Wood <david@davidtw.co>
(cherry picked from commit 24f90fdd2654e9c5437a684d3a72a4e70826a985)
Simplify this function a bit, it was quite hard to reason about.
Signed-off-by: David Wood <david@davidtw.co>
(cherry picked from commit 99b1897cf640d5f6dac74416761c9b3c75e1ef7a)
`()` is normally FFI-unsafe, but is FFI-safe when used as a return type.
It is also desirable that a transparent newtype for `()` is FFI-safe when
used as a return type.
In order to support this, when an type was deemed FFI-unsafe, because of
a `()` type, and was used in return type - then the type was considered
FFI-safe. However, this was the wrong approach - it didn't check that the
`()` was part of a transparent newtype! The consequence of this is that
the presence of a `()` type in a more complex return type would make it
the entire type be considered safe (as long as the `()` type was the
first that the lint found) - which is obviously incorrect.
Instead, this logic is removed, and a unit return type or a transparent
wrapper around a unit is checked for directly for functions and fn-ptrs.
Signed-off-by: David Wood <david@davidtw.co>
(cherry picked from commit f53cef31f5ea41c9a5ab8e5335637a6873b9f0b5)
