Closed
Conversation
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.
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
…is_rust()` with rustc
…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.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@e7d90c6 Filtered ref: rust-lang/rust-analyzer@bf9b8b9 Upstream diff: rust-lang/rust@c78a294...e7d90c6 This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
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 `Internator::Consts`, changes `Branch(Box<[I::Const]>)` to `Branch(I::Consts)`, and updates all relevant places.
r? lcnr
…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
…ority, r=Kivooeo Add high-priority ICEs to tests/crashes As of when I opened this PR, these two issues, rust-lang#146965 and rust-lang#150263, have been assigned as P-high. Per [the dev guide](https://rustc-dev-guide.rust-lang.org/tests/compiletest#crash-tests), I am adding these "untracked" crashes to the test suite, if that's okay with the relevant stakeholders. (I used to contribute to [glacier](https://github.com/rust-lang/glacier) about 5-6 years ago. Let me know if anything needs to change in these tests.)
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.
rustbot
added
A-attributes
Member
Author
|
@bors r+ rollup=never p=5 |
Contributor
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 6, 2026
Rollup of 7 pull requests Successful merges: - #153466 (`rust-analyzer` subtree update) - #151280 (Fix incorrect trailing comma suggested in no_accessible_fields) - #152593 (Box in `ValTreeKind::Branch(Box<[I::Const]>)` changed to `List`) - #153189 (refactor: move `check_align` to `parse_alignment`) - #153230 (Roll rustfmt reviewers for in-tree rustfmt) - #153321 (Add high-priority ICEs to tests/crashes) - #153445 (Consider try blocks as block-like for overflowed expr)
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
bot
added
S-waiting-on-review
Contributor
|
💔 Test for 882984e failed: CI. Failed job:
|
rust-bors
bot
added
S-waiting-on-author
Contributor
|
PR #153321, which is a member of this rollup, was unapproved. |
rustbot
removed
the
S-waiting-on-author
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
19 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:
rust-analyzersubtree update #153466 (rust-analyzersubtree update)ValTreeKind::Branch(Box<[I::Const]>)changed toList#152593 (Box inValTreeKind::Branch(Box<[I::Const]>)changed toList)check_aligntoparse_alignment#153189 (refactor: movecheck_aligntoparse_alignment)r? @ghost
Create a similar rollup