rustdoc: Improve sentence for documented empty impl blocks
Part of rust-lang/rust#152874.
An impl block is not necessarily empty, so instead, better to precise that there are no **public** items.
r? @Urgau
Superficial tweaks to the query modifier docs in `rustc_middle::query::modifiers`
This PR sorts the dummy items in the `modifiers` module, makes them non-pub to speed up find-all-references, and adds some extra explanation of what the dummy modifier items are for.
(These dummy items mostly just exist to carry documentation, and have no actual effect on compiler behaviour.)
fix interpreter tracing output
https://github.com/rust-lang/rust/pull/144708 accidentally changed the output of `MIRI_LOG=info <miri run>` in two ways:
- by adding `stmt=`/`terminator=` prefixes
- by changing the statement printing to be a verbose debug version instead of MIR pretty-printing
This fixes both of these:
- use explicit format strings to avoid the prefixes
- fix inconsistency in Debug impls for MIR types: now both TerminatorKind and StatementKind are pretty-printed, and Terminator and Statement just forward to the *Kind output
Revert relative paths for std links in rustc-docs
Reverts rust-lang/rust#152243.
The relative path `../` passed via `--extern-html-root-url` produces broken links in compiler documentation. The path is wrong in both the published layout (`doc.rust-lang.org/nightly/nightly-rustc/` vs `doc.rust-lang.org/nightly/core/`) and local builds (`compiler-doc/` vs `doc/`).
This restores absolute URLs via `#[doc(html_root_url)]`.
Fixesrust-lang/rust#152917
Re-opens rust-lang/rust#151496
cc @eggyal
Enable rust.remap-debuginfo in the dist profile
Anyone who distributes rustc almost certainly wants to enable this option. It is necessary for reproducibility and for a distributed rustc local paths are useless anyway. And finally it improves privacy if you distribute a local build.
Simplify ThinLTO handling
This reduces the amount of complexity around ThinLTO module buffers. It removes duplication between `ModuleBuffer` and `ThinBuffer` (the latter was also used for fat LTO in some cases), clarifies when and where the ThinLTO summary is used (only for `--emit thin-link-bitcode`, ThinLTO performed by rustc rebuilds the summary every time). This also enables a follow up cleanup to reduce code duplication between red, green and imported codegen units.
Part of https://github.com/rust-lang/compiler-team/issues/908
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.
Simplify `size/align_of_val<T: Sized>` to `size/align_of<T>` instead
This is relevant to things like `Box<[u8; 1024]>` where the drop looks at the `size_of_val` (since obviously it might be DST in general) but where we don't actually need to do that since it's always that same value for the `Sized` type.
(Equivalent to rust-lang/rust#152681, but flipped in the rebase so it can land before rust-lang/rust#152641 instead of depending on it.)
Perform many const checks in typeck
Some smaller diagnostic changes, the biggest ones avoided by https://github.com/rust-lang/rust/pull/148641
We should be able to move various checks in mir const checking to using `span_bug!` instead of reporting an error, just like mir typeck does as a sanity check. I would like to start doing so separately though, as this PR is a big enough (in what effects it causes, pun intended).
r? @fee1-dead
