Skip to content
Prev Previous commit
Next Next commit
remove an unnecessary negation
I think in this case the early return is harder to read than just an if.
"if fallback hasn't occured we don't do..."
  • Loading branch information
WaffleLapkin committed Nov 13, 2025
commit a137c21278cb3ed3b66102ed31e9518afa750840
52 changes: 25 additions & 27 deletions compiler/rustc_hir_typeck/src/fallback.rs
Original file line number Diff line number Diff line change
Expand Up @@ -49,34 +49,32 @@ impl<'tcx> FnCtxt<'_, 'tcx> {

let fallback_occurred = self.fallback_types();

if !fallback_occurred {
return;
if fallback_occurred {
// We now see if we can make progress. This might cause us to
// unify inference variables for opaque types, since we may
// have unified some other type variables during the first
// phase of fallback. This means that we only replace
// inference variables with their underlying opaque types as a
// last resort.
Comment on lines +56 to +58
Copy link
Contributor

Choose a reason for hiding this comment

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

existing, but I do not understand that comment?

Do you understand what this wants to say. It feels like this is a general "if fallback occurred, previously stalled goals may make progress again".

I really don't see how there's anything specific to opaques here.

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't get it either .-.

the example below is supposed to explain this, but I still don't get it

Copy link
Contributor

Choose a reason for hiding this comment

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

hmm, want to rip this out and replace it with

if fallback occurred, previously stalled goals may make progress again

even if this comment was somehow relevant, given that we both don't get what it means, I don't think it does us any good

//
// In code like this:
//
// ```rust
// type MyType = impl Copy;
// fn produce() -> MyType { true }
// fn bad_produce() -> MyType { panic!() }
// ```
//
// we want to unify the opaque inference variable in `bad_produce`
// with the diverging fallback for `panic!` (e.g. `()` or `!`).
// This will produce a nice error message about conflicting concrete
// types for `MyType`.
//
// If we had tried to fallback the opaque inference variable to `MyType`,
// we will generate a confusing type-check error that does not explicitly
// refer to opaque types.
self.select_obligations_where_possible(|_| {});
}

// We now see if we can make progress. This might cause us to
// unify inference variables for opaque types, since we may
// have unified some other type variables during the first
// phase of fallback. This means that we only replace
// inference variables with their underlying opaque types as a
// last resort.
//
// In code like this:
//
// ```rust
// type MyType = impl Copy;
// fn produce() -> MyType { true }
// fn bad_produce() -> MyType { panic!() }
// ```
//
// we want to unify the opaque inference variable in `bad_produce`
// with the diverging fallback for `panic!` (e.g. `()` or `!`).
// This will produce a nice error message about conflicting concrete
// types for `MyType`.
//
// If we had tried to fallback the opaque inference variable to `MyType`,
// we will generate a confusing type-check error that does not explicitly
// refer to opaque types.
self.select_obligations_where_possible(|_| {});
}

fn fallback_types(&self) -> bool {
Expand Down