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
Add missing closing brackets to THIR output.
Closing brackets were missing on AdtDef, the field_types list in FruInfo, and InlineAsmExpr, breaking folding in some editors; Fields were incorrectly (?) indexed in the list for functional update syntax, showing the (implicit, irrelevant) iteration index instead of the field index; also spurious colon after Pat.
Add an additional help note to the ambiguity lint error
This PR adds an additional help note to the ambiguity lint error output to ask users updating their dependencies. This hopefully helps with cases like rust-lang/rust#149845 where newer crate versions are fixed.
r? @petrochenkov
Ship LLVM (`rust-dev`) in fast try builds again
https://github.com/rust-lang/rust/pull/142963 stopped shipping `rust-dev` in fast try builds, which was not actually correct, because if a PR modifies the LLVM submodule, we should provide the prebuilt LLVM for rustc-perf even in a (fast) try build. So why didn't we find out about this earlier? Well, because soon before that PR landed, we started using new bors for try builds, which actually broke bootstrap's git change detection logic, because new bors used a different e-mail address for merge commits.
So the two bugs kind of masked each other out. Recently, we fixed the e-mail address and git change detection with new bors, since it's now also used for auto builds, but that in turn broke fast try builds that modify LLVM (https://github.com/rust-lang/rust/pull/150722#issuecomment-3756545084), because rustc-perf saw that LLVM was modified in the try build, and it (correctly!) tried to download `rust-dev` for the given try build commit, but that was (incorrectly!) missing on CI, due to being skipped.
This PR restored building the `rust-dev` component in fast try builds. In theory, we could use the same git detection logic that bootstrap uses and only do this if LLVM is actually modified in the given commit, but I'd rather do the correct thing here, than introduce additional opportunities for the git detection to desync.
Closing brackets were missing on AdtDef, the field_types list in FruInfo, and InlineAsmExpr, breaking folding in some editors;
Fields were incorrectly (?) indexed in the list for functional update syntax, showing the (implicit, irrelevant) iteration index instead of the field index;
also spurious colon after Pat.
Clean up `rustc_attr_parsing`
Follow-up of rust-lang/rust#150934.
It removes the `Option<>` wrapping for `SharedContext::target` field and completely removed the `target_id` field. Considering this type contains a closure and never updates its `target_id` field, there is no need to keep it around, it can be used directly in the lint emitter.
r? @JonathanBrouwer
