Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework MatchType recursion in collectParts #19867

Merged
merged 1 commit into from
Mar 6, 2024

Commits on Mar 4, 2024

  1. Rework MatchType recursion in collectParts

    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.
    dwijnand committed Mar 4, 2024
    Configuration menu
    Copy the full SHA
    f0cd565 View commit details
    Browse the repository at this point in the history