Skip to content

Fix match_same_arms FP with associated consts#16701

Merged
samueltardieu merged 1 commit intorust-lang:masterfrom
profetia:issue16698
Mar 10, 2026
Merged

Fix match_same_arms FP with associated consts#16701
samueltardieu merged 1 commit intorust-lang:masterfrom
profetia:issue16698

Conversation

@profetia
Copy link
Copy Markdown
Member

@profetia profetia commented Mar 10, 2026

Closes #16698

changelog: [match_same_arms] fix FP with associated consts

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Mar 10, 2026
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Mar 10, 2026

r? @samueltardieu

rustbot has assigned @samueltardieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: 7 candidates
  • 7 candidates expanded to 7 candidates
  • Random selection from Jarcho, dswij, llogiq, samueltardieu

Copy link
Copy Markdown
Member

@samueltardieu samueltardieu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't look like the proper fix. If you create two crates, one containing the definition and impls of Foo as found in the issue, and one depending on it containing the match statement, the bug will still be present.

View changes since this review

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Mar 10, 2026
@profetia
Copy link
Copy Markdown
Member Author

You are right. I think the proper fix might be changing const-eval equivalence of two exprs from default to an option.

@samueltardieu
Copy link
Copy Markdown
Member

You are right. I think the proper fix might be changing const-eval equivalence of two exprs from default to an option.

Can't you just check that the constant belongs to an inherent impl and not a trait?

Wouldn't this work?

                    && let Some((DefKind::AssocConst { .. }, did)) = self.typeck.type_dependent_def(id)
                    && self.tcx.inherent_impl_of_assoc(did).is_some() =>

@Jarcho
Copy link
Copy Markdown
Contributor

Jarcho commented Mar 10, 2026

That is correct. The only thing you need to do is make sure the constant is from an inherent impl and not a trait impl.

@profetia
Copy link
Copy Markdown
Member Author

Indeed. Thanks for both of you :)

@profetia
Copy link
Copy Markdown
Member Author

Though what I'm considering is that is it really proper for match_same_arms to consider exprs evaluting to the same constant as same, for example:

match true {
    false => 1 + 1,
    true => 0 + 2,
};

@samueltardieu samueltardieu added this pull request to the merge queue Mar 10, 2026
Merged via the queue into rust-lang:master with commit c2178bb Mar 10, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

match_same_arms false positive with associated constants

4 participants