Skip to content

Conversation

@zedddie
Copy link
Contributor

@zedddie zedddie commented Jan 26, 2026

Fixes #151462

Transmutability error reporting hit an ICE when type aliases were normalized for diagnostics. For example, when type
JustUnit = () normalizes to (), the check passes unexpectedly even though the original check with JustUnit failed.

Fixed by adding a retry in the Answer::Yes arm that checks with the root obligation's types before panicking. The retry only occurs when the root obligation differs and is a Transmute trait predicate.

Also added a test that reproduces the original ICE.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 26, 2026
@rustbot
Copy link
Collaborator

rustbot commented Jan 26, 2026

r? @jdonszelmann

rustbot has assigned @jdonszelmann.
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

Comment on lines +2922 to +2925
if obligation.predicate != root_obligation.predicate {
if let ty::PredicateKind::Clause(ty::ClauseKind::Trait(root_pred)) =
root_obligation.predicate.kind().skip_binder()
&& root_pred.def_id() == trait_pred.trait_ref.def_id
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
if obligation.predicate != root_obligation.predicate {
if let ty::PredicateKind::Clause(ty::ClauseKind::Trait(root_pred)) =
root_obligation.predicate.kind().skip_binder()
&& root_pred.def_id() == trait_pred.trait_ref.def_id
if obligation.predicate != root_obligation.predicate
&& let ty::PredicateKind::Clause(ty::ClauseKind::Trait(root_pred)) =
root_obligation.predicate.kind().skip_binder()
&& root_pred.def_id() == trait_pred.trait_ref.def_id

@Kivooeo
Copy link
Member

Kivooeo commented Jan 26, 2026

Btw, I'm curious, there is a comment

// Should never get a Yes at this point! We already ran it before, and did not get a Yes.

If I understand this correctly, we should never reach this branch, but for some point we do, this brings me to believe that the problem occurs somewhere earlier

@zedddie
Copy link
Contributor Author

zedddie commented Jan 26, 2026

Yes, I've thought about this too, and I tried to use root obligation check earlier to leave the Answer::Yes arm untouched, but it seems to regress diagnostics like bool-mut test(/tests/ui/transmutability/primitives/bool-mut.stderr) from

error[E0277]: `u8` cannot be safely transmuted into `bool`
   ^^^^^^^^^^^^^^^ at least one value of `u8` isn't a bit-valid value of `bool`

to

error[E0277]: `&mut bool` cannot be safely transmuted into `&mut u8`
   ^^^^^^^^^^^^^^^ unsatisfied trait bound
   = help: the nightly-only, unstable trait `TransmuteFrom<u8, ...>` is not implemented for `bool`

which looks incorrect to me. I've thought about this and recheck with root obligation to ensure we are dealing with same type in the Answer::Yes seems reasonable. If it is an incorrect approach I'd like to reimplement this check earlier in error reporting logic, leaving Answer::Yes untouched.

@zedddie
Copy link
Contributor Author

zedddie commented Jan 26, 2026

Actually, It seems to be there is a better place for this check which will not cause diagnostics regression, I will deal with that tommorow

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

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[ICE]: Inconsistent rustc_transmute::is_transmutable(...) result, got Yes

4 participants