New MIR Pass: SsaRangePropagation
As an alternative to https://github.com/rust-lang/rust/pull/150192.
Introduces a new pass that propagates the known ranges of SSA locals.
We can know the ranges of SSA locals at some locations for the following code:
```rust
fn foo(a: u32) {
let b = a < 9;
if b {
let c = b; // c is true since b is whitin the range [1, 2)
let d = a < 8; // d is true since b whitin the range [0, 9)
}
}
```
This PR only implements a trivial range: we know one value on switch, assert, and assume.
Port rustc allocator attributes to attribute parser
Tracking issue: rust-lang/rust#131229
Made a new file since i saw this pattern for `rustc_dump.rs`
Very simple attributes so felt like I can do them all in one PR
r? @JonathanBrouwer
fix: thread creation failed on the wasm32-wasip1-threads target.
wasm32-wasip1-threads target cannot create thread since nightly-2026-01-16.
This commit (c1bcae0638) broken it.
It in https://github.com/rust-lang/rust/pull/151016
This pull-request fix that issue.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#150767 (Allow invoking all help options at once)
- rust-lang/rust#150886 (Added mGCA related tests)
- rust-lang/rust#151245 (Explicitly list crate level attrs)
- rust-lang/rust#151268 (Fix ICE on inconsistent import resolution with macro-attributed extern crate)
- rust-lang/rust#151275 (Normalize type_const items even with feature `generic_const_exprs`)
- rust-lang/rust#151288 (Use `find_attr` instead of `attr::contains_name` in `lower_const_item_rhs`)
- rust-lang/rust#151321 (Port #![no_main] to the attribute parser.)
r? @ghost
Use `find_attr` instead of `attr::contains_name` in `lower_const_item_rhs`
Fixesrust-lang/rust#151250
`attr::contains_name` uses `AttributeExt::name()` to filter, but for `hir::Attribute::Parsed`, this method will return `None`, and then `attr::contains_name` will return `false` here. So that the previous logic cannot work as expected.
r? @BoxyUwU
Normalize type_const items even with feature `generic_const_exprs`
Fixesrust-lang/rust#151251
With feature `generic_const_exprs` enabled, consts with `#[type_const]` won't be normalized even if they need. Then ICE happens when CTFE tries to evaluate such const without body.
Fix this by normalizing such consts even with feature `generic_const_exprs` enabled.
r? @BoxyUwU
Fix ICE on inconsistent import resolution with macro-attributed extern crate
Fixesrust-lang/rust#151213 using issue_145575_hack_applied in the same way as in rust-lang/rust#149860.
Allow invoking all help options at once
Implements rust-lang/rust#150442
Help messages are printed in the order they are invoked, but only once (e.g. `--help -C help --help` prints regular help then codegen help).
Lint groups (`-Whelp`) are always printed last due to necessarily coming later in the compiler pipeline.
Adds `help` flags to `-C` and `-Z` to avoid an error in `build_session_options`.
cc @bjorn3 [#t-compiler/major changes > Allow combining `--help -C help -Z help -… compiler-team#954 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Allow.20combining.20.60--help.20-C.20help.20-Z.20help.20-.E2.80.A6.20compiler-team.23954/near/564358190) - this currently maintains the behaviour of unrecognized options always failing-fast, as this happens within `getopt`s parsing, before we can even check if help options are present.
Supress some lookup errors if a module contains `compile_error!`
The problem is that when a macro expand to `compile_error!` because its input is malformed, the actual error message from the `compile_error!` might be hidden in a long list of other messages about using items that should have otherwise been generated by the macro.
So suppress error about missing items in that module.
Fixesrust-lang/rust#68838
The problem is that when a macro expand to `compile_error!` because
its input is malformed, the actual error message from the
`compile_error!` might be hidden in a long list of other messages about
using items that should have otherwise been generated by the macro.
So suppress error about missing items in that module.
Fixes issue 68838
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#148769 (Stabilize `alloc_layout_extra`)
- rust-lang/rust#150200 (Add title field to `ice.md` issue template)
- rust-lang/rust#150955 (Underscore-prefixed bindings are explicitly allowed to be unused)
- rust-lang/rust#151200 (time: Add saturating arithmetic for `SystemTime`)
- rust-lang/rust#151235 (Change field `bit_width: usize` to `bits: u32` in type info)
- rust-lang/rust#151242 (Port #[needs_allocator] to attribute parser)
- rust-lang/rust#151274 (Include a link to `count_ones` in the docs for `uN::count_zeros` [docs only])
- rust-lang/rust#151279 (remove trailing periods in built-in attribute gate messages)
r? @ghost
Port #[needs_allocator] to attribute parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
Ports needs_allocator attribute to the new attribute parser.
Note: this is a deprecated and feature gated attribute.
time: Add saturating arithmetic for `SystemTime`
This commit implements the following methods:
* `SystemTime::saturating_add`
* `SystemTime::saturating_sub`
* `SystemTime::saturating_duration_since`
The implementation of these methods is rather trivial, as the main logic lies behind the constants `SystemTime::MIN` and `SystemTime::MAX`.
See also:
* Accepted ACP: rust-lang/libs-team#718
* Tracking Issue: rust-lang/rust#151199
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
Zalathar