Skip to content

Rollup of 13 pull requests#153498

Closed
JonathanBrouwer wants to merge 80 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-Zhp15EP
Closed

Rollup of 13 pull requests#153498
JonathanBrouwer wants to merge 80 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-Zhp15EP

Conversation

@JonathanBrouwer
Copy link
Contributor

Successful merges:

r? @ghost

Create a similar rollup

chenyukang and others added 30 commits January 18, 2026 11:16
both operands of binary operators (including compound assignments like
`+=`) were inferred with `ExprIsRead::No`, which prevented divergence
detection for place expressions of type `!`. this caused false type
mismatches when a function's return type depended on the block diverging
after something like `x += *never_ptr` or `let _ = *never_ptr + 1`.
both operands of any binary operator are always consumed (read), so this
uses `ExprIsRead::Yes` to be consistent with the ordinary assignment and
let binding paths.
Signed-off-by: arferreira <arfs.antonio@gmail.com>
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
Example
---
```rust
fn main() {
    match 2 {
        bar => &bar.l$0
    }
}
```

**Before this PR**

```text
sn deref         *expr
sn match match expr {}
```

**After this PR**

```text
sn deref         *expr
sn let             let
sn letm        let mut
sn match match expr {}
```
Example
---
```rust
struct Foo { bar: i32, baz: i32 }

impl Foo {
    fn foo(&mut $0self) {
        self.bar = 5;
    }
}
```

**Before this PR**

Assist not applicable

**After this PR**

```rust
struct Foo { bar: i32, baz: i32 }

impl Foo {
    fn foo(&mut self) {
        let Foo { bar, baz } = self;
        *bar = 5;
    }
}
```
- Remove unused `ast::make::match_arm_with_guard`

Example
---
```rust
fn main() {
    if true {
        $0if true
            && false
        {
            foo()
        }
    }
}
```

**Before this PR**

```rust
fn main() {
    if true {
        match true
            && false {
            true => foo(),
            false => (),
        }
    }
}
```

**After this PR**

```rust
fn main() {
    if true {
        match true
            && false
        {
            true => foo(),
            false => (),
        }
    }
}
```
Bumps [minimatch](https://github.com/isaacs/minimatch) from 3.1.2 to 3.1.5.
- [Changelog](https://github.com/isaacs/minimatch/blob/main/changelog.md)
- [Commits](isaacs/minimatch@v3.1.2...v3.1.5)

---
updated-dependencies:
- dependency-name: minimatch
  dependency-version: 3.1.5
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
fix: Fix wrong confiditon in `Visibility::min`
…er-coercion

fix: use `ExprIsRead::Yes` for rhs of binary operators
…yarn/editors/code/minimatch-3.1.5

build(deps-dev): bump minimatch from 3.1.2 to 3.1.5 in /editors/code
Example
---
```rust
macro_rules! m { ($expr:expr) => {$expr}}
enum Test {
    A,
    B,
    C,
}

fn foo(t: Test) {
    m!(match t {
        Test::A => (),
    $0});
}
```

**Before this PR**

Assist not applicable

**After this PR**

```rust
macro_rules! m { ($expr:expr) => {$expr}}
enum Test {
    A,
    B,
    C,
}

fn foo(t: Test) {
    m!(match t {
        Test::A=>(),
        Test::B => ${1:todo!()},
        Test::C => ${2:todo!()},$0
    });
}
```
This updates the rust-version file to e7d90c6.
rust-analyzer allows AI usage (see rust-lang#21314), but requires contributors
to declare usage. This adds a rule file that improves LLM output
quality and instructs the LLM to declare usage in commit messages.

I've written the rules in CLAUDE.md, but also symlinked it to
AGENTS.md so other LLM tools pick it up.

## Rules file contents

(1) Instructions for both humans and AIs to declare AI usage.

(2) Relevant commands for testing, linting and codegen.

Note that I deliberately didn't include an overview of the project
structure on a folder-by-folder basis. This can go stale, and there's
some evidence that project structure can hurt LLM output quality
overall.

See the following paper:

> Evaluating AGENTS.md:
> Are Repository-Level Context Files Helpful for Coding Agents?
> https://arxiv.org/pdf/2602.11988

## Testing

I exercised this change with the following contrived prompt. Note that
in practice rust-analyzer is hitting review scaling limits for new
code actions, but it was easy to test end-to-end.

> Add a new code action that replaces the content of a string literal
> with the text "banana".
...
> commit it

This produced a functional code action with both Codex and Claude, and
in both cases the commit message mentioned that it was AI
generated. Example commit message:

    Add "Replace string with banana" code action

    Add a new assist that replaces a string literal's content with "banana"
    when the cursor is on a STRING token.

    AI: Generated with Claude Code (claude-opus-4-6).

I confirmed that the code action worked by testing a rust-analyzer
build in Emacs, and also confirmed that the generated tests looked
sensible.

## AI Usage Disclosures

I wrote the first draft of the rules file with Opus 4.6, manually
reviewed everything.
…nd-range

fix: Fix wrong descend range for add_missing_match_arms
…s-rust

Fix: align `is_rust()` with rustc by correcting constructor ABI in next solver
…tebank

Fix incorrect trailing comma suggested in no_accessible_fields

Fixes rust-lang#149787

r? @estebank

I think add new field for AST for it is too heavy change for this issue, here is a trivial fix with source_map, seems enough for it.
Box in `ValTreeKind::Branch(Box<[I::Const]>)` changed to `List`

This is related to trait system refactoring. It fixes the FIXME in `ValTreeKind`

```
   // FIXME(mgca): Use a `List` here instead of a boxed slice
    Branch(Box<[I::Const]>),
```

It introduces `Interner::Consts`, changes `Branch(Box<[I::Const]>)` to `Branch(I::Consts)`, and updates all relevant places.

r? lcnr
std: add wasm64 to sync::Once and thread_parking atomics cfg guards

When targeting `wasm64-unknown-unknown` with atomics enabled, `std::sync::Once` and `thread_parking` fall through to the `no_threads`/`unsupported` implementations because the cfg guards only check for `wasm32`. This causes worker threads to panic with `unreachable` at runtime. The underlying futex implementations already handle both wasm32 and wasm64 correctly, only the cfg guards were missing wasm64.

I tested this manually with a multithreaded wasm64 application ([o1js](https://github.com/o1-labs/o1js/)) compiled with `-Z build-std=panic_abort,std` and `-C target-feature=+atomics,+bulk-memory,+mutable-globals`

Related: rust-lang#83879 rust-lang#77839

Happy to adjust anything based on feedback
…oss35

libcore float tests: replace macro shadowing by const-compatible macro

This lets us avoid rust-lang#153478.
However this means we generate 3 function items per assertion -- or rather, 3*8, since every assertion gets duplicated 8 times (4 float types, each in a const and a non-const variant). That's a lot; is it enough to be concerned about?
coretest already takes forever to build. In a quick test, build time increased from 29.8s to 30.8s, but that may also entirely be noise.

r? @tgross35
…ery, r=petrochenkov

Fix ICE in `offset_of!` error recovery

Fixes rust-lang#153236.

`offset_of!` was changed in rust-lang#148151 to lower through THIR as a sum of calls to the `offset_of` intrinsic. In the error-recovery case, when no valid field indices are recorded, that lowering synthesized `0` as a `u32` even though the overall `offset_of!` expression has type `usize`.

On 64-bit targets, const-eval then tried to write a 4-byte immediate into an 8-byte destination, which caused the ICE.
Do not emit ConstEvaluatable goals if type-const

Fixes rust-lang#151631, fixes rust-lang#151477
r? @fmease

I'd recommend reviewing commit-by-commit, the diff is less-readable to address a cyclic issue.
…-destructuring-drop, r=estebank,Kivooeo

Suppress invalid suggestions in destructuring assignment

Fixes rust-lang#152694

When destructuring assignment hits a type with `Drop`, the compiler was emitting two broken suggestions: `ref *&mut String::new()` (invalid syntax) and `.clone()` on a temporary (useless).

Root cause: the suggestion logic didn't know these bindings were synthetic from assign desugaring. The fix reuses the existing `AssignDesugar` detection in `BindingFinder` to collect those spans and skip both suggestions.
…tor_1, r=JonathanBrouwer

refactor: move `check_align` to `parse_alignment`

Part of rust-lang#153101

r? @JonathanBrouwer

PS: jonathan i'm not sure about what to do with `check_align` now
…tfmt, r=ytmimi

Roll rustfmt reviewers for in-tree rustfmt

Noticed in rust-lang#153229 (comment), where because `src/tools/rustfmt` has no corresponding `[assign.owners]` entry, it rolls one of the `fallback` reviewers (Mark and me) which is needless indirection, since if it rolls to Mark, Mark will have to reroll again.

This _can_ also be

```toml
"/src/tools/rustfmt" = ["rustfmt", "rustfmt-contributors"]
```

which corresponds to https://github.com/orgs/rust-lang/teams/rustfmt and https://github.com/orgs/rust-lang/teams/rustfmt-contributors respectively. I will double-check with triagebot team if we can use review rotation toggles for `rust-lang/rust` in-tree `rustfmt` specifically.

Discussion: [#t-rustfmt > review queue tracking for rust-lang/rust in-tree rustfmt](https://rust-lang.zulipchat.com/#narrow/channel/357797-t-rustfmt/topic/review.20queue.20tracking.20for.20rust-lang.2Frust.20in-tree.20rustfmt/with/576498516)

### Unresolved question

- ~~Do we want to start everyone off as off-rotation? Or on-rotation? I plan to start conservatively by preserving existing effective status, which is everyone off-rotation.~~ We will match existing defaults, with everyone starting off as off-team-rotation.

r? @ytmimi
Consider try blocks as block-like for overflowed expr

The tracking issue for `try_blocks` is rust-lang#31436.
The tracking issue for `try_blocks_heterogeneous` is rust-lang#149488.

Fixes rust-lang/rustfmt#6799.
…fmease

Preserve parentheses around `Fn` trait bounds in pretty printer

The AST pretty printer was dropping parentheses around `Fn` trait bounds in `dyn`/`impl` types when additional `+` bounds were present. For example:

    dyn (FnMut(&mut T) -> &mut dyn ResourceLimiter) + Send + Sync

was pretty-printed as:

    dyn FnMut(&mut T) -> &mut dyn ResourceLimiter + Send + Sync

Without parens, `+ Send + Sync` binds to the inner `dyn ResourceLimiter` instead of the outer type, producing invalid Rust.

The parser already tracks parentheses via `PolyTraitRef.parens`, but `print_poly_trait_ref` never checked this field. This adds `popen()` and `pclose()` calls when `parens == Parens::Yes`.
@rust-bors rust-bors bot added the rollup A PR which is a rollup label Mar 6, 2026
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-meta Area: Issues & PRs about the rust-lang/rust repository itself S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rust-analyzer Relevant to the rust-analyzer team, which will review and decide on the PR/issue. T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue. labels Mar 6, 2026
@JonathanBrouwer
Copy link
Contributor Author

@bors r+ rollup=never p=5

@JonathanBrouwer
Copy link
Contributor Author

Trying commonly failed jobs
@bors try jobs=test-various,x86_64-gnu-aux,x86_64-gnu-llvm-21-3,x86_64-msvc-1,aarch64-apple,x86_64-mingw-1

@rust-bors
Copy link
Contributor

rust-bors bot commented Mar 6, 2026

📌 Commit 5d3972a has been approved by JonathanBrouwer

It is now in the queue for this repository.

@rust-bors rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 6, 2026
@rust-bors

This comment has been minimized.

rust-bors bot pushed a commit that referenced this pull request Mar 6, 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
@rust-bors
Copy link
Contributor

rust-bors bot commented Mar 6, 2026

☀️ Try build successful (CI)
Build commit: 1d235d9 (1d235d98778f5034e5f0070dc25bdcb944f77d32, parent: ff086354c9fc93e1da1d2f4d255456624fbcd099)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-meta Area: Issues & PRs about the rust-lang/rust repository itself rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rust-analyzer Relevant to the rust-analyzer team, which will review and decide on the PR/issue. T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.