You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This patch fixes a recursion situation in collectParts, by
reimplementing a previous fix. Recursion is already attempted to be
cutoff with `partSeen`, and `handleRecursion` is also used to prevent
any unhandled recursion situations (like the one fixed here) from
crashing the compiler.
For context, AppliedType aren't hash-consed (i.e. the flyweight pattern)
which means that every time you apply the same type arguments to the
same type constructor you get a fresh AppliedType. Using i18171 as an
example, the sequence of events where this matters is:
0. When typing BAZ, so much earlier than the collectParts call, because
the MatchType on the rhs of BAZ reduces at definition site, the RHS
is reduced to the `DFVal[BAZREC[T]]`, which means that BAZ's info is
a TypeAlias rather than a MatchAlias, meaning it can dealias.
1. `BAZREC[Any]` is extracted by MatchType.InDisguise, which applies the
Any to return a fresh MatchType
2. `Tuple.Map[Any, BAZ]` is also extracted by MatchType.InDisguise,
which returns its own fresh MatchType
3. `BAZ[h]` dealiases to a fresh `DFVal[BAZREC[h]]` instance (see step 0)
4. `BAZREC[h]` is extracted by MatchType.InDisguise, repeating the cycle
The reason that the cases with MatchType.InDisguise and MatchType were
introduced is i17395. Looking back, it seems the only need is to
capture any parts that are in the reduction of an applied MatchType.
With this patch applied in the case of i18171, this now cuts off
quickly, as `BAZREC[Any]` doesn't reduce to anything. In the case of
i17395, `ExtractPart[ValuePartHolder]` reduces to `Value`, so `Value` is
successfully recorded as a part.
0 commit comments