Rollup of 13 pull requests#154242
Closed
JonathanBrouwer wants to merge 34 commits intorust-lang:mainfrom
Closed
Conversation
Currently, building std for a custom Wasm target with an OS other than `unknown` will fail, because `sys/alloc/mod.rs` will attempt to use `sys/alloc/wasm.rs`, the dlmalloc-based allocator used on `wasm32-unknown-unknown`. However, currently dlmalloc is only pulled in when `target_os = "unknown"`. Instead, we should make `Cargo.toml` and `alloc/mod.rs` match: either - disable `wasm.rs` in `alloc/mod.rs` where `not(target_os = "unknown")`, or - pull in `dlmalloc` for all Wasm targets with `target_family = "wasm32"` that aren't covered by the [upper branches of `alloc/mod.rs`](https://github.com/rust-lang/rust/blob/main/library/std/src/sys/alloc/mod.rs#L72-L100). This PR takes the latter approach, because it allows more code to compile without a custom allocator.
The AST pretty printer was dropping parentheses around or-patterns
when they appeared inside `@` bindings, `&` references, or `box`
patterns. For example:
- `v @ (1 | 2 | 3)` was printed as `v @ 1 | 2 | 3`
- `&(1 | 2 | 3)` was printed as `&1 | 2 | 3`
- `box (1 | 2 | 3)` was printed as `box 1 | 2 | 3`
Since `|` has the lowest precedence among pattern operators, all of
these are parsed incorrectly without parentheses — e.g. `v @ 1 | 2 | 3`
becomes `(v @ 1) | 2 | 3`, binding `v` only to the first alternative.
This caused E0408 ("variable not bound in all patterns") when the
expanded output was fed back to the compiler, affecting crates like
html5ever and wgpu-core that use macros expanding to or-patterns
after `@`.
The fix adds a `print_pat_paren_if_or` helper that wraps `PatKind::Or`
subpatterns in parentheses, and uses it in the `@`, `&`, and `box`
printing arms. This is similar in spirit to the existing `FixupContext`
parenthesization approach used for expression printing.
Signed-off-by: Andrew V. Teylu <andrew.teylu@vector.com>
The pretty printer now correctly parenthesizes or-patterns inside `box` patterns, which changes the Clippy `unnested_or_patterns` lint suggestion from `box box (0 | 2 | 4)` to `box (box (0 | 2 | 4))`. The new output is more correct — the old suggestion was itself missing parens and would have been parsed as `box (box 0) | 2 | 4`. Signed-off-by: Andrew V. Teylu <andrew.teylu@vector.com>
This matters for `x test rustc_transmute`, where the feature won't automatically be enabled and as a result spew a bunch of warnings.
When encountering an unmet predicate, when we point at the trait impls that do exist, if they are all for the same self type, tweak the wording to make it less verbose.
It's very small and only has two call sites. The tiny loss of DRY is worth it to shrink `QueryVTable`.
We can only reach this point if `try_load_from_disk_fn` fails, and the
condition of this assertion is basically just the inverse of what
`try_load_from_disk_fn` does. Basically it's like this:
```
fn foo() -> bool { a && b }
fn bar() {
if foo() {
return;
}
assert!(!a || !b);
}
```
The assertion is just confusing and provides little value.
Crates with different overflow-checks settings accessing the same RangeFromIter resulted in incorrect values being yielded
…ions Avoid unconditionally slicing `inputs()[1..]`, which assumes a `self` parameter. Use `is_method()` to conditionally skip the receiver, preventing out-of-bounds access and fixing suggestions for associated functions. Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>
This one just irritates me, and I don't think it adds much value.
by - using `DiagSymbolList` to get nicely formatted lists - mentioning the `modifier` when an invalid modifier is used. This is useful in case the span cannot be resolved (which I ran into).
By removing the early return and using a `match` instead. - The two paths are of similar conceptual weight, and `match` reflects that. - This lets the `incremental_verify_ich` call be factored out.
We've already stabilized float operations in const, which means we've already accepted that a `const fn` might behave differently in consteval vs at run time.
`std`: include `dlmalloc` for all non-wasi Wasm targets Currently, building std for a custom Wasm target with an OS other than `unknown` will fail, because `sys/alloc/mod.rs` will attempt to use `sys/alloc/wasm.rs`, the dlmalloc-based allocator used on `wasm32-unknown-unknown`. However, currently dlmalloc is only pulled in when `target_os = "unknown"`. Instead, we should make `Cargo.toml` and `alloc/mod.rs` match: either - disable `wasm.rs` in `alloc/mod.rs` where `not(target_os = "unknown")`, or - pull in `dlmalloc` for all Wasm targets with `target_family = "wasm32"` that aren't covered by the [upper branches of `alloc/mod.rs`](https://github.com/rust-lang/rust/blob/main/library/std/src/sys/alloc/mod.rs#L72-L100). This PR takes the latter approach, because it allows more code to compile without a custom allocator.
…rk-Simulacrum bootstrap: Pass `--features=rustc` to rustc_transmute This matters for `x test rustc_transmute`, where the feature won't automatically be enabled and as a result spew a bunch of warnings.
…=jdonszelmann Remove `ATTRIBUTE_ORDER` r? @jdonszelmann There's only a few attributes that use `KeepInnermost` and I think I like the consistency of just making them all `KeepOutermost`
…yukang [BPF] add target feature allows-misaligned-mem-access This PR adds the allows-misaligned-mem-access target feature to the BPF target. The feature can enable misaligned memory access support in the LLVM backend, aligning Rust’s BPF target behavior with the corresponding LLVM update introduced in [llvm/llvm-project#167013](llvm/llvm-project#167013) (included in LLVM 22).
…chenyukang
Parenthesize or-patterns in prefix pattern positions in pretty printer
The AST pretty printer was dropping parentheses around or-patterns when they appeared inside `@` bindings, `&` references, or `box` patterns. For example:
- `v @ (1 | 2 | 3)` was printed as `v @ 1 | 2 | 3`
- `&(1 | 2 | 3)` was printed as `&1 | 2 | 3`
- `box (1 | 2 | 3)` was printed as `box 1 | 2 | 3`
Since `|` has the lowest precedence among pattern operators, all of these are parsed incorrectly without parentheses — e.g. `v @ 1 | 2 | 3` becomes `(v @ 1) | 2 | 3`, binding `v` only to the first alternative.
This caused E0408 ("variable not bound in all patterns") when the expanded output was fed back to the compiler, affecting crates like html5ever and wgpu-core that use macros expanding to or-patterns after `@`.
The fix adds a `print_pat_paren_if_or` helper that wraps `PatKind::Or` subpatterns in parentheses, and uses it in the `@`, `&`, and `box` printing arms. This is similar in spirit to the existing `FixupContext` parenthesization approach used for expression printing.
## Example
**before** (`rustc 1.96.0-nightly (3b1b0ef 2026-03-11)`):
```rust
#![feature(prelude_import)]
#![no_std]
#![feature(box_patterns)]
extern crate std;
#[prelude_import]
use ::std::prelude::rust_2015::*;
//@ pretty-compare-only
//@ pretty-mode:expanded
//@ pp-exact:or-pattern-paren.pp
macro_rules! or_pat { ($($name:pat),+) => { $($name)|+ } }
fn check_at(x: Option<i32>) {
match x {
Some(v @ 1 | 2 | 3) =>
{
::std::io::_print(format_args!("{0}\n", v));
}
_ => {}
}
}
fn check_ref(x: &i32) { match x { &1 | 2 | 3 => {} _ => {} } }
fn check_box(x: Box<i32>) { match x { box 1 | 2 | 3 => {} _ => {} } }
fn main() { check_at(Some(2)); check_ref(&1); check_box(Box::new(1)); }
```
**after** (this branch):
```rust
#![feature(prelude_import)]
#![no_std]
#![feature(box_patterns)]
extern crate std;
#[prelude_import]
use ::std::prelude::rust_2015::*;
//@ pretty-compare-only
//@ pretty-mode:expanded
//@ pp-exact:or-pattern-paren.pp
macro_rules! or_pat { ($($name:pat),+) => { $($name)|+ } }
fn check_at(x: Option<i32>) {
match x {
Some(v @ (1 | 2 | 3)) =>
{
::std::io::_print(format_args!("{0}\n", v));
}
_ => {}
}
}
fn check_ref(x: &i32) { match x { &(1 | 2 | 3) => {} _ => {} } }
fn check_box(x: Box<i32>) { match x { box (1 | 2 | 3) => {} _ => {} } }
fn main() { check_at(Some(2)); check_ref(&1); check_box(Box::new(1)); }
```
Notice `v @ 1 | 2 | 3` becomes `v @ (1 | 2 | 3)`, `&1 | 2 | 3` becomes `&(1 | 2 | 3)`, and `box 1 | 2 | 3` becomes `box (1 | 2 | 3)`. Without parens, the or-pattern binds incorrectly — only the first alternative gets the `@`/`&`/`box`, causing E0408.
refactor RangeFromIter overflow-checks impl Crates with different overflow-checks settings accessing the same RangeFromIter resulted in incorrect values being yielded Fixes rust-lang#154124 r? @tgross35
…, r=Zalathar Refactor query loading Some refactoring of code relating to query result loading. Details in individual commits. r? @Zalathar
…, r=jdonszelmann drop derive helpers during attribute parsing
…st, r=RalfJung Document consteval behavior of ub_checks, overflow_checks, is_val_statically_known.
…e-modifier, r=nnethercote Improve inline assembly error messages by - using `DiagSymbolList` to get nicely formatted lists - mentioning the `modifier` when an invalid modifier is used. This is useful in case the span cannot be resolved (which I ran into).
rustbot
added
A-attributes
Contributor
Author
|
@bors r+ rollup=never p=3 |
Contributor
Contributor
Author
|
Trying commonly failed jobs |
rust-bors
bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 23, 2026
Rollup of 13 pull requests try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
bot
added
S-waiting-on-author
Contributor
|
PR #153041, which is a member of this rollup, was unapproved. This rollup was thus unapproved. |
rustbot
removed
the
S-waiting-on-author
rust-bors
bot
added
the
S-waiting-on-author
Contributor
|
💔 Test for 3b3ebe8 failed: CI. Failed jobs:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
std: includedlmallocfor all non-wasi Wasm targets #153686 (std: includedlmallocfor all non-wasi Wasm targets)--features=rustcto rustc_transmute #154105 (bootstrap: Pass--features=rustcto rustc_transmute)ATTRIBUTE_ORDER#153041 (RemoveATTRIBUTE_ORDER)r? @ghost
Create a similar rollup