explain rigid aliases

This commit is contained in:
lcnr 2024-03-22 10:40:58 +01:00 committed by Boxy
parent 0c4c6d79a8
commit f1698b1270
1 changed files with 3 additions and 1 deletions

View File

@ -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 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 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 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. The underlying value may itself be an unnormalized alias, e.g.
`NormalizesTo(<<() as Id>::This as Id>::This)` only returns `<() as Id>::This`, `NormalizesTo(<<() as Id>::This as Id>::This)` only returns `<() as Id>::This`,