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.

Sign up for GitHub

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

Jump to bottom

More aggressive reduction of type selection (fixes parboiled2) #14987

Merged
merged 2 commits into from Apr 21, 2022
Merged

More aggressive reduction of type selection (fixes parboiled2) #14987

merged 2 commits into from Apr 21, 2022

Commits on Apr 20, 2022

  1. More aggressive reduction of type selection (fixes parboiled2) 

    Previously, when reducing `a.T` we checked if the type of `a` was a subtype of
`RefinedType(.., T, TypeAlias(...))`, now we extend this check to handle
refinements where the `info` is a `TypeBounds` where both bounds are equal.

This solves two big issues at once:
- We can restore tests/pos/13491.scala to its original form from before scala#13780.
  The check for abstract types introduced by scala#13780 for soundness reasons is no
  longer hit because the type selection is reduced before we get to that point.
  This is important because parboiled2 relies on this and is therefore currently
  broken on 3.1.3-RC1 and main (sirthias/parboiled2#365).
- This fixes scala#14903 (slow compilation issue affecting parboiled2) without
  caching skolems (as in the alternative fix scala#14909). Again, this is due to the
  type containing skolem being reducible to a simpler type and therefore cacheable.
    @smarter
    smarter committed Apr 20, 2022
    Configuration menu
    Copy the full SHA
    be9c8be View commit details
    Browse the repository at this point in the history

  2. lookupRefined: check for AliasingBounds instead of TypeBounds with eq… 

    …ual bounds

It turns out that the problematic cases fixed in the previous commit only occurs
because we create type aliases with info of type MatchAlias instead of TypeAlias
if their rhs is an applied match type (Namer#TypeDefCompleter#typeSig calls
`toBounds` on the rhs which does `if (self.isMatch) MatchAlias(self)`).

I'm not sure if there is a good reason for that (and if so, do we need to be
careful to avoid loops when dealiasing MatchAlias?) or if we should change the
logic in Namer to return a TypeAlias instead.
    @smarter
    smarter committed Apr 20, 2022
    Configuration menu
    Copy the full SHA
    e0cce9a View commit details
    Browse the repository at this point in the history