Add regression test for const parameter default ICE
Closesrust-lang/rust#142913
This adds a UI regression test for a fixed ICE where a const generic parameter
type mentioned an earlier lifetime and also had a default value.
The reproducer is the minimized version posted in the issue.
Tested:
- ./x test tests/ui/const-generics/generic_const_parameter_types/region-parameter-out-of-range-ice-142913.rs --force-rerun
- ./x test tidy --bless
Fix doc typo in Vec::into_array and convert Arc/Box/Rc::into_arry to -> Result
Hello 🪼,
the first commit fixes a documentation mistake added in the recent PR rust-lang/rust#156234
The second commit addresses three function signature changes as defined by the tracking issue rust-lang/rust#148082
It converts all `.into_array() -> Option<>` into `.into_array() -> Result<>`
The third commit is a fixup for the second. The change is needed as calling `unwrap()` on `Err(E)` requires `E` to implement `Debug`. I thought `Vec<T, A> where T: Debug` is not an acceptable solution, so I tried to come up with my own. I am *NOT* confident in my `unsafe {}` code due to lack of expierence, please check extra carefully.
Appreciating feedback & greetings from the RustWeek,
Thanks!
[single_use_lifetimes]: Account for lifetime bounds
This PR makes `single_use_lifetimes` account for bounds on lifetime parameters, so a lifetime such as `'b` in `<'a, 'b: 'a>` is not treated as single-use just because its bound is stored separately from ordinary lifetime uses.
Fixesrust-lang/rust#153836
Add `#[doc(alias = "phi")]` for float `GOLDEN_RATIO` constants
- Adds "phi" doc alias for `f16`, `f32`, `f64`, and `f128`
I knew this constant was stabilized but I couldn't remember what it was called.
Searching "phi" in the docs only surfaces the π constant, `is_ascii_graphic`, and `spin_loop_hint` methods. This alias would make it much easier to find.
https://doc.rust-lang.org/nightly/std/?search=phi
Add unstable Share trait
Tracking issue: rust-lang/rust#156756
This adds an initial unstable `Share` trait for clone-as-alias types, as part of the 2026 ergonomic ref-counting project goal.
```rust
pub trait Share: Clone {
fn share(&self) -> Self {
Clone::clone(self)
}
}
```
This PR adds a separate unstable feature gate:
```rust
#![feature(share_trait)]
```
and places the trait next to `Clone` in `core::clone`.
Implemented initial impls:
- `impl<T: ?Sized> Share for &T`
- `impl<T: ?Sized, A: Allocator + Clone> Share for Rc<T, A>`
- `impl<T: ?Sized, A: Allocator + Clone> Share for Arc<T, A>`
- `impl<T> Share for std::sync::mpsc::Sender<T>`
- `impl<T> Share for std::sync::mpsc::SyncSender<T>`
The PR deliberately does not add `Share` to the prelude.
r? @nikomatsakis
@rustbot label F-ergonomic_clones
Fix reborrow_info early return skipping field validation
`reborrow_info` validates that all data fields of a struct implementing `Reborrow` are either `Copy` or themselves `Reborrow`. When iterating the fields, finding a `Reborrow` field returned `Ok(())` immediately, so any remaining fields were never validated. This let a struct with a non-`Copy`, non-`Reborrow` second field implement `Reborrow`.
Changing the early `return Ok(())` to `continue` makes the loop validate every field.
Tracking issue: rust-lang/rust#145612
Use print instead of po in debuginfo path test
Fixesrust-lang/rust#156660
This fixes `tests/debuginfo/path.rs` failing on newer Apple LLDB versions.
Root cause:
Apple LLDB 2100 reports missing Rust language plugin support:
warning: `po` was unsuccessful, running `p` instead
As a result, `po` falls back to `p`, producing expanded output that no longer matches the existing `lldb-check` directives.
Changes:
- replace `po` with `print`
- relax `lldb-check` expectations using `[...]`
- preserve validation of the displayed path value
This also aligns `path.rs` with the rest of the debuginfo tests, as it appears to be the only test using `po`.
---
EDIT(@jieyouxu): see digging https://github.com/rust-lang/rust/pull/156769#discussion_r3293345899
Fix jump to def link generation on primitive type associated methods
Fixesrust-lang/rust#156707.
Interestingly enough, the inference fails on primitive type, so instead I go around a bit by generating a `PrimitiveType` and then tweak a bit the `href` generation.
r? @fmease
Stop needing materialized places for most intrinsics
Today even to return a constant from `size_of_val` it takes an `alloca`. That's wasteful.
This updates the cg_ssa traits to allow returning an `OperandValue` instead, which is possible for the vast majority of intrinsics -- this PR moves all but 5 over to doing that in LLVM.
The first commit adds a test to help show the difference here.
cc https://github.com/rust-lang/compiler-team/issues/970https://github.com/rust-lang/rust/issues/153250
Also emit "Dyn Compatibility" section for traits that *are* dyn compatible
I was using the std docs to check if a trait was dyn compatible, and was very confused that it had no info about dyn compatibility. I had to go look at a trait that I knew for certain was *not* dyn compatible (`Clone`) to verify that we still had the dyn compatibility section, and that its omission meant a trait *was* compatible.
(also removed the "..., so this trait is not object safe" text because it seemed pretty redundant)
r? @fmease
Turn `lint_index` from `Option<u16>` to `u16` for LintExpectationId
While doing lint attributes PR, I realised that the field `lint_index` didn't need to be Optional
(this PR is part of a series of PRs that will make the lint attrs PR more easily reviewable)
r? @nnethercote because you did rust-lang/rust#156596 recently
rustfmt: format const trait impls to `const impl` for syntax transition
Because this concerns rustc development (we want this in next beta) so that we can ensure by the next beta rustc can remove the parser support for `impl const Trait`, this PR is made against the r-l/r repo :)
Fix reborrow ICE in MIR place lowering
## Summary
Fixesrust-lang/rust#156482.
This fixes an internal THIR/MIR contract inconsistency for generic reborrow expressions.
`ExprKind::Reborrow` is lowered into MIR as `Rvalue::Reborrow`, but MIR expression categorization treated it as place-like while `expr_as_place` treated evaluating it as a place as unreachable. That caused the rust-lang/rust#156482 ICE, where the compiler panicked with `entered unreachable code` in `expr_as_place` while building MIR for a generic reborrow expression.
The fix makes the MIR builder contract explicit: a reborrow expression is rvalue-producing. Its source may be a place, but the reborrow expression itself is not an assignable place.
## What changed
- Updated MIR expression categorization so `ExprKind::Reborrow` is categorized as rvalue-producing rather than place-like.
- Updated place lowering so reborrow follows the normal rvalue temporary-materialization path if a place is needed.
- Added a targeted UI regression test covering the exact rust-lang/rust#156482 repro.
cc @aapoalas
Remove stale RTN FIXME for assoc item constraint fallback
The old FIXME suggested that this diagnostic path should emit a `return_type_notation` feature-gate diagnostic.
That is no longer correct: RTN associated item constraints now use `(..)`, so a form like `Trait<method(): Bound>` is not made valid by enabling `return_type_notation`.
This PR removes the stale FIXME without changing the diagnostic behavior.
compiler: fix duplicated "the" in two doc-comments
Two one-line typo fixes for duplicated "the" in compiler doc-comments:
- `compiler/rustc_type_ir/src/solve/mod.rs` — "only if any of the the opaques in the opaque type storage has a hidden type" → "...any of the opaques in..."
- `compiler/rustc_borrowck/src/diagnostics/var_name.rs` — "/// Find the the name and span of the variable corresponding to the given region." → "/// Find the name and span of the variable corresponding to the given region."
No code/behavior change.
Allow forbidden target features to be hard errors
Sometimes when adding a new target features to the list of known target features, we want to completely forbid them from being used because they are ABI affecting and should be target modifiers instead. As such, we want to issue an error rather than a warning since there are no future compatibility concerns .
r? @workingjubilee since you're familiar with the motivating case in rust-lang/rust#136597
If I rebase that PR on top of this locally, then we get the following error messages when trying to activate the SLS target feature (note that they are *errors* not *warnings* and we've omitted the usual note about future compatibility):
```
error: target feature `harden-sls-ijmp` cannot be enabled with `-Ctarget-feature`: use `harden-sls` compiler flag instead
error: target feature `harden-sls-ret` cannot be enabled with `-Ctarget-feature`: use `harden-sls` compiler flag instead
error: aborting due to 2 previous errors
```
Install additional LLVM DLL on Windows
Fixes https://github.com/rust-lang/rust/issues/155268
The problem is that with shared linking to LLVM lib we have binaries requiring it in `$sysroot/bin` and `$sysroot/lib/rustlib/triple/bin`, but place the DLL only in the first location. On Unix systems rpath would take care of that, but on Windows the required DLL must be next to the binary or be found in PATH.
This PR puts another copy of the library into that second location. The size overhead of such copy compared to static linking is much lower than I anticipated even though I couldn't manage to make bootstrap create hard links.
The sizes without and with `llvm-tools` component:
```
❯ du --summarize -h .rustup/toolchains/{additional-dll,static}*
638M .rustup/toolchains/additional-dll
800M .rustup/toolchains/additional-dll-tools
608M .rustup/toolchains/static-link
1.1G .rustup/toolchains/static-link-tools
```
Statically linked LLD sits at 139M while dynamically linked one is 7.5M + 150M for the libLLVM, so the difference is minor.
Alternatively, we could require that on Windows, binaries located in `$sysroot/lib/rustlib/triple/bin` must always be called with `$sysroot/bin` in the PATH. However, that sounds like something that would require an announcement and some grace period.
[Debug Info] Gracefully handle invalid `String`/`Vec`
Somewhat related to https://github.com/rust-lang/rust/issues/150392.
Currently the handling can throw an exception, which we should absolutely not do. It causes issues with debugger adapters (e.g. CodeLLDB will hang forever. Trying to stop the debugger via vscode's interface causes a CodeLLDB to leak memory constantly until RAM is depleted and the OS starts killing processes). The exception has been replaced with a printed error message and a placeholder value.
Additionally, if a String/Vec is in an "invalid" state due to niche optimization (`capacity >= (1 << 63)`, common with `Option<String>`/`Option<Vec<T>>`), the pointer and length values will be meaningless, but are not guaranteed to be 0'd. The debugger will happily proceed as if they are useful values, and often do things like \<try to read multiple GB of data from the debugee\>.
I added simple checks to ensure that the capacity and length are within bounds, and that the pointer is non-null. If any check fails, the string/vec just acts as if it's empty.
Eventually this problem will be solved on LLDB's end via https://github.com/llvm/llvm-project/pull/188487/ or similar, but preventing issues on our end in the short term will help a lot.
---
try-job: aarch64-apple
Jacob Pratt