Skip to content

Commit

Permalink
explain rigid aliases
Browse files Browse the repository at this point in the history
  • Loading branch information
lcnr authored and BoxyUwU committed Mar 22, 2024
1 parent 0c4c6d7 commit f1698b1
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion src/solve/normalization.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,9 @@ One-step normalization is implemented via `NormalizesTo` goals. Unlike other goa
in the trait solver, `NormalizesTo` always expects the term to be an unconstrained
inference variable[^opaques]. Think of it as a function, taking an alias as input
and returning its underlying value. If the alias is rigid, `NormalizesTo` fails and
returns `NoSolution`.
returns `NoSolution`. This is the case for `<T as Trait>::Assoc` if there's a `T: Trait`
where-bound and for opaque types with `Reveal::UserFacing` unless they are in the
defining scope. We must not treat any aliases as rigid in coherence.

The underlying value may itself be an unnormalized alias, e.g.
`NormalizesTo(<<() as Id>::This as Id>::This)` only returns `<() as Id>::This`,
Expand Down

0 comments on commit f1698b1

Please sign in to comment.