Currently the rustfmt slow test fails if you don't have a nightly
toolchain installed. We install a nightly toolchain on CI, but it's a
little confusing that tests can fail on a fresh checkout on a new
laptop.
Instead, skip this test if there's no nightly toolchain.
the `check_ptr_ptr_cast` function had an early return when the source and
destination dyn trait objects shared the same principal trait def id:
if src_principal == dst_principal {
return Ok(());
}
this bypassed all three remaining checks that the code comment explicitly
listed as required: generic argument equality, projection equality, and
the auto-trait superset check. as a result, casts like
`*mut dyn Trait as *mut (dyn Trait + Send)` were silently accepted
instead of emitting E0804.
the fix removes the early return. `CastError::PtrPtrAddingAutoTraits` and
its diagnostic were already implemented — they just couldn't be reached.
the supertrait case (`trait Trait: Send`) continues to work correctly
because the auto-trait check already accounts for implied auto traits via
supertrait elaboration.
Rollup of 14 pull requests
Successful merges:
- rust-lang/rust#150468 (rustc_target: callconv: powerpc64: Use the ABI set in target options instead of guessing)
- rust-lang/rust#151628 (Fix ICE in const eval of packed SIMD types with non-power-of-two element counts)
- rust-lang/rust#151871 (don't use env with infer vars)
- rust-lang/rust#152591 (Simplify internals of `{Rc,Arc}::default`)
- rust-lang/rust#152865 (Fixed ByteStr not padding within its Display trait when no specific alignment is mentioned)
- rust-lang/rust#147859 (reduce the amount of panics in `{TokenStream, Literal}::from_str` calls)
- rust-lang/rust#152705 (Test(lib/win/proc): Skip `raw_attributes` doctest under Win7)
- rust-lang/rust#152767 (fix typo in `carryless_mul` macro invocation)
- rust-lang/rust#152837 (fix(codegen): Use `body_codegen_attrs` For Caller In `adjust_target_feature_sig`)
- rust-lang/rust#152871 (Fix warnings in rs{begin,end}.rs files)
- rust-lang/rust#152879 (Remove `impl IntoQueryParam<P> for &'a P`.)
- rust-lang/rust#152933 (Start migration for `LintDiagnostic` items by adding API and migrating `LinkerOutput` lint)
- rust-lang/rust#152937 (remove unneeded reboxing)
- rust-lang/rust#152953 (Fix typo in armv7a-vex-v5.md)
Start migration for `LintDiagnostic` items by adding API and migrating `LinkerOutput` lint
This is more or less the same approach as https://github.com/rust-lang/rust/pull/152811, but in a much smaller size to make it reviewable. A lot of PRs will follow though. :)
This PR creates the equivalent of `lint_level` working with `Diagnostic` and add new methods on `MultiSpan` to make it work as well (in particular because we need to copy messages/spans from one context to another).
r? @JonathanBrouwer
Remove `impl IntoQueryParam<P> for &'a P`.
`IntoQueryParam` is a trait that lets query callers be a bit sloppy with the passed-in key.
- Types similar to `DefId` will be auto-converted to `DefId`. Likewise for `LocalDefId`.
- Reference types will be auto-derefed.
The auto-conversion is genuinely useful; the auto-derefing much less so. In practice it's only used for passing `&DefId` to queries that accept `DefId`, which is an anti-pattern because `DefId` is marked with `#[rustc_pass_by_value]`.
This commit removes the auto-deref impl and makes the necessary sigil adjustments. (I generally avoid using `*` to deref manually at call sites, preferring to deref via `&` in patterns or via `*` in match expressions. Mostly because that way a single deref often covers multiple call sites.)
r? @cjgillot
fix(codegen): Use `body_codegen_attrs` For Caller In `adjust_target_feature_sig`
### Summary:
#### Problem:
Coercing a `#[target_feature]` `const fn` to a function pointer inside a `const` body triggers an ICE (debug builds only):
```rust
#[target_feature(enable = "sse2")]
const fn with_target_feature() {}
const X: () = unsafe {
let _: unsafe fn() = with_target_feature; // ICE
};
```
```text
assertion failed: def_kind.has_codegen_attrs()
unexpected `def_kind` in `codegen_fn_attrs`: Const
```
#### Root Cause:
Introduced in rust-lang/rust#135504 (2025-01-14, commit `8fee6a77394`). `adjust_target_feature_sig` unconditionally calls `codegen_fn_attrs(caller)` to get the caller's target features. `codegen_fn_attrs` requires that the `DefId` satisfies `has_codegen_attrs()`. `DefKind::Const`, `AssocConst`, and `InlineConst` do not — they have no codegen attributes by design. The debug assertion fires.
In release builds the call "worked" accidentally: `codegen_fn_attrs` on a const would reach the query machinery and happen to return empty attributes, producing a correct (but unguaranteed) result. The bug was latent until debug builds exposed it.
#### Solution:
Replace `codegen_fn_attrs(caller)` with `body_codegen_attrs(caller)`. `body_codegen_attrs` exists precisely for this case: it delegates to `codegen_fn_attrs` for function-like `DefKind`s and returns `CodegenFnAttrs::EMPTY` for const items. A const body has no target features, so returning empty is semantically correct.
Also fix the pre-existing variable name `callee_features` → `caller_features` (the variable holds the *caller*'s features, not the callee's).
### Changes:
- `compiler/rustc_middle/src/ty/context.rs`: `adjust_target_feature_sig` — use `body_codegen_attrs` for `caller`; rename `callee_features` → `caller_features`.
- `tests/ui/target-feature/const-target-feature-fn-ptr-coercion.rs`: regression test covering `Const`, `AssocConst`, and `InlineConst` caller contexts.
Fixesrust-lang/rust#152340.
Test(lib/win/proc): Skip `raw_attributes` doctest under Win7
The current doctest for `ProcThreadAttributeListBuilder::raw_attribute` uses `CreatePseudoConsole`, which is only available on Windows 10 October 2018 Update and above. On older versions of Windows, the test fails due to trying to link against a function that is not present in the kernel32 DLL. This therefore ensures the test is still built, but not run under the Win7 target.
@rustbot label T-libs A-process A-doctests O-windows-7
reduce the amount of panics in `{TokenStream, Literal}::from_str` calls
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/147859)*
Before this PR, calling `TokenStream::from_str` or `Literal::from_str` with an invalid argument would always cause a compile error, even if the `TokenStream` is not used afterwards at all.
This PR changes this so it returns a `LexError` instead in some cases.
This is very theoretically a breaking change, but the doc comment on the impl already says
```
/// NOTE: some errors may cause panics instead of returning `LexError`. We reserve the right to
/// change these errors into `LexError`s later.
```
Fixes some cases of rust-lang/rust#58736.
Simplify internals of `{Rc,Arc}::default`
This commit simplifies the internal implementation of `Default` for these two pointer types to have the same performance characteristics as before (a side effect of changes in rust-lang/rust#131460) while avoid use of internal private APIs of Rc/Arc. To preserve the same codegen as before some non-generic functions needed to be tagged as `#[inline]` as well, but otherwise the same IR is produced before/after this change.
The motivation of this commit is I was studying up on the state of initialization of `Arc` and `Rc` and figured it'd be nicer to reduce the use of internal APIs and instead use public stable APIs where possible, even in the implementation itself.
Fix ICE in const eval of packed SIMD types with non-power-of-two element counts
fixesrust-lang/rust#151537
const evaluation of packed SIMD types with non-power-of-two element counts (like `Simd<_, 3>`) was hitting an ICE. the issue was in `check_simd_ptr_alignment` - it asserted that `backend_repr` must be `BackendRepr::SimdVector`, but for packed SIMD types with non-power-of-two counts the compiler uses `BackendRepr::Memory` instead (as mentioned in `rustc_abi/src/layout.rs:1511`).
was fixed by making `check_simd_ptr_alignment` accept both `BackendRepr::SimdVector` and `BackendRepr::Memory` for SIMD types. added a check to ensure we're dealing with a SIMD type, and the alignment logic works the same for both representations.
also i added a test that reproduces the original ICE.
rustc_target: callconv: powerpc64: Use the ABI set in target options instead of guessing
All PowerPC64 targets except AIX explicitly set the ABI in the target options. We can therefore stop hardcoding the ABI to be used based on the target environment or OS, except for the AIX special case.
The fallback based on endianness is kept for the sake of compatibility with custom targets.
This makes it so that big endian targets not explicitly accounted for before (powerpc64-unknown-openbsd) and targets that don't use the expected default ABI (big-endian ELFv2 Glibc targets) use the correct ABI in the calling convention code.
The second commit is a tiny change to validate the `llvm_abiname` set on PowerPC64(LE) targets. See the commit messages for details.
CC @RalfJung who pointed out the missing `llvm_abiname` validation
The convert_if_to_bool_then assist was producing incorrect code when
the Some branch was in the else arm and the condition was a method call
expression (e.g. is_empty()).
Before:
if test.is_empty() { None } else { Some(()) }
was incorrectly rewritten to:
test.is_empty().then(|| ())
After (correct):
(!test.is_empty()).then(|| ())
Root cause: the parenthesization check ran on the original condition
before inversion. When invert_boolean_expression produced a PrefixExpr
(e.g. !test.is_empty()), it was not being parenthesized because the
check had already passed on the original MethodCallExpr.
Fix: move the parenthesization check to after the inversion step so it
correctly detects PrefixExpr and wraps it in parentheses.
A regression test has been added to cover this case.
