From abe38f2db059f149a46f9175dccf6bd264d727ad Mon Sep 17 00:00:00 2001
From: lcnr <rust@lcnr.de>
Date: Fri, 22 Mar 2024 10:40:58 +0100
Subject: [PATCH] explain rigid aliases

---
 src/solve/normalization.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/solve/normalization.md b/src/solve/normalization.md
index 25bb5c783..eaf4e1b11 100644
--- a/src/solve/normalization.md
+++ b/src/solve/normalization.md
@@ -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`,