[beta] backports, plus stable versions in stdarch
- Replace `stdarch` version placeholders with 1.94
- Parse ident with allowing recovery when trying to diagnose rust-lang/rust#151249
- Revert enabling `outline-atomics` on various platforms rust-lang/rust#151896
- Revert doc attribute parsing errors to future warnings rust-lang/rust#151952
- Remove the 4 failing tests from rustdoc-gui rust-lang/rust#152194
- Remove rustdoc GUI flaky test rust-lang/rust#152116
- Align `ArrayWindows` trait impls with `Windows` rust-lang/rust#151613
- Fix suppression of `unused_assignment` in binding of `unused_variable` rust-lang/rust#151556
- layout: handle rigid aliases without params rust-lang/rust#151814
- Fix missing unused_variables lint when using a match guard rust-lang/rust#151990
- Partially revert "resolve: Update `NameBindingData::vis` in place" rust-lang/rust#152498
- [BETA]: parse array lengths without stripping const blocks rust-lang/rust#152237
r? cuviper
Within a binding pattern match guard, only real reads of a bound local
impact its liveness analysis - not the fake read that is injected.
(cherry picked from commit 5aba6b1635)
aliases may be rigid even if they don't reference params. If the alias isn't well-formed, trying to normalize it as part of the input should have already failed
(cherry picked from commit 39a532445a)
Unused assignments to an unused variable should trigger only the
`unused_variables` lint and not also the `unused_assignments` lint.
This was previously implemented by checking whether the span of the
assignee was within the span of the binding pattern, however that failed
to capture situations was imported from elsewhere (eg from the input
tokenstream of a proc-macro that generates the binding pattern).
By comparing the span of the assignee to those of the variable
introductions instead, a reported stable-to-stable regression is
resolved.
This fix also impacted some other preexisting tests, which had
(undesirably) been triggering both the `unused_variables` and
`unused_assignments` lints on the same initializing assignment; those
tests have therefore now been updated to expect only the former lint.
(cherry picked from commit 22b3f59882)
The derived `T: Copy` constraint is not appropriate for an iterator by
reference, but we generally do not want `Copy` on iterators anyway.
(cherry picked from commit 2bae85ec52)
Add `const Default` impls for `HashSet` and `HashMap` with custom `Hasher`
Follow up to rust-lang/rust#134628. Tracking issue rust-lang/rust#143894.
r? @fmease
cc @fee1-dead @oli-obk
This doesn't allow for `const H: HashSet<()> = Default::default();`, but would allow for it to work with a custom hasher, which would enable the `Fx*` family to work.
Fix ICE: When Trying to check visibility of a #[type_const], check RHS instead.
This PR fixes https://github.com/rust-lang/rust/issues/150956 for min_const_generic_args https://github.com/rust-lang/rust/issues/132980.
The first part of this PR checks in `reachable.rs` if we have a type const use `visit_const_item_rhs(init);` instead of calling `const_eval_poly_to_alloc()`
The second part is I noticed that if `const_eval_poly_to_alloc()` returns a `ErrorHandled::TooGeneric` then switches to `visit_const_item_rhs()`. So further up `const_eval_poly_to_alloc()` call order it eventual gets to `eval_in_interpreter()`. So I added a debug_assert in `eval_in_interpreter()` if we happen to try and run CTFE on a `type_const`.
The other bit is just a test case, and some duplicated code I noticed.
While the PR does get rid of the ICE for a type_const with `pub` visibility. If I try using the const though it will ICE with the following:
```
error: internal compiler error: /home/keith/GitHub/rust_kc/compiler/rustc_const_eval/src/check_consts/qualifs.rs:355:13: expected ConstKind::Param or ConstKind::Value here, found UnevaluatedConst { def: DefId(20:4 ~ colorkit[c783]::TYPE_CONST), args: [] }
thread 'rustc' (819687) panicked at /home/keith/GitHub/rust_kc/compiler/rustc_const_eval/src/check_consts/qualifs.rs:355:13:
```
I suspect it is a similar issue to inherent associated consts. Since if I apply the same fix I had here:
https://github.com/rust-lang/rust/pull/150799#discussion_r2676504639
I then can use the const internally and in external crates without any issues.
Although, did not include that fix since if it is a similar issue it would need to be addressed elsewhere.
r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args
remove multiple unhelpful `reason = "..."` values from `#[unstable(...)]` invocations
The vast majority of `#[unstable()]` attributes already has no explicit reason specified. This PR removes the `reason = "..."` value for the following unhelpful or meaningless reasons:
* "recently added"
* "new API"
* "recently redesigned"
* "unstable"
An example of how the message looks with and without a reason:
```rust
fn main() {
Vec::<()>::into_parts;
Vec::<()>::const_make_global;
}
```
```
error[E0658]: use of unstable library feature `box_vec_non_null`: new API
--> src/main.rs:2:5
|
2 | Vec::<()>::into_parts;
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #130364 <https://github.com/rust-lang/rust/issues/130364> for more information
= help: add `#![feature(box_vec_non_null)]` to the crate attributes to enable
= note: this compiler was built on 2026-01-15; consider upgrading it if it is out of date
error[E0658]: use of unstable library feature `const_heap`
--> src/main.rs:3:5
|
3 | Vec::<()>::const_make_global;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #79597 <https://github.com/rust-lang/rust/issues/79597> for more information
= help: add `#![feature(const_heap)]` to the crate attributes to enable
= note: this compiler was built on 2026-01-15; consider upgrading it if it is out of date
```
Most of the remaining reasons after this are something similar to "this is an implementation detail for XYZ" or "this is not public". If this PR is approved, I'll look into those next.
The PR also removes the `fd_read` feature gate. It only consists of one attribute applied to an implementation inside a module that is already private and unstable and should not be needed.
We want to evaluate the rhs of a type_const.
Also added an early return/guard in eval_in_interpreter which is used in functions like `eval_to_allocation_raw_provider`
Lastly add a debug assert to `thir_body()` if we have gotten there with a type_const something as gone wrong.
Get rid of a call to is_type_const() and instead use a match arm.
Change this is_type_const() check to a debug_assert!()
Change to use an if else statment instead.
Update type_const-pub.rs
Fix formatting.
Noticed that this is the same check as is_type_const() centralize it.
Add test case for pub type_const.
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#151092 (Generate macro expansion for rust compiler crates docs)
- rust-lang/rust#151120 (Fix deprecated attribute intra-doc link not resolved in the right location on reexported item)
- rust-lang/rust#151207 (Preliminary match/capture test cleanup for PR 150681)
- rust-lang/rust#151221 (Reorganizing `tests/ui/issues` 5 tests [1/N])
- rust-lang/rust#151222 (feat: Support references in reflection type info)
r? @ghost
Preliminary match/capture test cleanup for PR 150681
Review for rust-lang/rust#150681 requested that this cleanup gets extracted to a separate PR.
r? @Zalathar
Fix deprecated attribute intra-doc link not resolved in the right location on reexported item
Fixes https://github.com/rust-lang/rust/issues/151028.
Follow-up of https://github.com/rust-lang/rust/pull/150721.
So when we resolve an intra-doc link, its current context (the module from which we resolve in short) is very important. However, when we use an intra-doc link in a `#[deprecated]` attribute on a reexported item, we were using the context of the reexported item and not of the `use` itself. Meaning that if you have an intra-doc link `std::mem::drop` on an item from another crate (let's say `core`), then the import will simply fail since there is no `std` dependency.
Now comes the not so funny fix: at this point, we don't know anymore where the attribute came from (ie, from the reexport or from the reexported item) since we already merged the attribute at this point. The solution I found to go around this problem is to check if the item span contains the attribute, and if not, then we use the `inline_stmt_id` as context instead of the item's ID. I'm not super happy and I'm sure we'll find corner cases in the future (like with macros), however there are a few things that mitigate this fix:
1. The only way to generate an attribute with a macro with its item while having different spans is by using proc-macros. In that case, we can always default to the `inline_stmt_id` as context and be fine, but I guess we'll see when get there.
2. It only concerns reexports, so the area of the problem is quite restricted.
Hopefully this explanation made sense. :)
cc @folkertdev
r? @lolbinarycat
Update cargo submodule
15 commits in 8c133afcd5e0d69932fe11f5907683723f8d361d..85eff7c80277b57f78b11e28d14154ab12fcf643
2026-01-09 03:50:15 +0000 to 2026-01-15 16:18:08 +0000
- fix(lockfile): switch to `resolver.lockfile-path` config (rust-lang/cargo#16510)
- Moved build-script bins to `deps` directory (rust-lang/cargo#16515)
- Invalidate the whole build cache when `-Zno-embed-metadata` changes (rust-lang/cargo#16513)
- Do not create examples dir in build dir with new layout (rust-lang/cargo#16514)
- fix(git): avoid partial oid got zero padded (rust-lang/cargo#16511)
- Optimize cargo locate-project --workspace (rust-lang/cargo#16423)
- chore: Update typos (rust-lang/cargo#16507)
- refactor(git): remove unnecessary serialization (rust-lang/cargo#16505)
- fix(build-std): std link metadata propagate to user (rust-lang/cargo#16496)
- Improve error message for missing dependencies (rust-lang/cargo#16500)
- fix: preserve `dep_name` for build script metadata (rust-lang/cargo#16494)
- refactor(toml): clarify `to_dependency` for config patch (rust-lang/cargo#16492)
- Add `--id` flag to `cargo report timings` and `cargo report rebuilds` (rust-lang/cargo#16490)
- Display lockfile path in very verbose mode when blocking (rust-lang/cargo#16491)
- fix(info): resolve underscore vs hyphen mismatch in schema lookup (rust-lang/cargo#16455)
r? ghost
