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

SIP-56: Better foundations for match types #18262

Merged
merged 17 commits into from
Dec 18, 2023
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
17 commits
Select commit Hold shift + click to select a range
c96d847
Introduce MatchTypeCaseSpec to categorize match type cases.
sjrd Jul 20, 2023
5260c60
Use new specced match types for class type constructors.
sjrd Nov 24, 2023
cc41d48
Use new specced match types for `scala.compiletime.int.S[n]`.
sjrd Aug 4, 2023
067b828
Short-circuit match type cases with missing captures in their patterns.
sjrd Nov 24, 2023
aa8d348
Use the specced match types for abstract tycons in patterns.
sjrd Aug 4, 2023
97725d7
Handle type member extractors as specced match types.
sjrd Aug 8, 2023
7ab7b0f
Report a compile error on illegal match types.
sjrd Nov 24, 2023
ec94ff5
Allow to reduce type member extractors when the member is a class.
sjrd Nov 24, 2023
1b2a16e
New implementation of `provablyDisjoint` to match SIP-56.
sjrd Aug 17, 2023
f432d08
Be more specific about higher-kinded types in provablyDisjoint.
sjrd Aug 29, 2023
c653793
Do not use provablyEmpty anymore; use S <: T + provablyDisjoint(S, T)…
sjrd Nov 24, 2023
16cf4f2
Add regression tests for old issues fixed with the new match types.
sjrd Aug 30, 2023
c8b4da8
Under -source:3.3 and below, always use the legacy match type algorithm.
sjrd Nov 24, 2023
2dd9f45
In type assigner for Apply, carry ErrorType's from the `fn`.
sjrd Nov 29, 2023
ec097a9
Fix 1 cause of infinite recursion in the new provablyDisjoint.
sjrd Dec 18, 2023
b5a4ca5
Demonstrate more potential unsoundness with a CCE reproducer.
sjrd Dec 8, 2023
c3b9d9b
Add comments that link to relevant parts of the spec of SIP-56.
sjrd Dec 15, 2023
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 16 additions & 2 deletions compiler/src/dotty/tools/dotc/core/TypeComparer.scala
Original file line number Diff line number Diff line change
Expand Up @@ -2808,8 +2808,22 @@ class TypeComparer(@constructorOnly initctx: Context) extends ConstraintHandling
val optGadtBounds = gadtBounds(sym)
if optGadtBounds != null then disjointnessBoundary(optGadtBounds.hi)
else disjointnessBoundary(tp.superTypeNormalized)
case tp @ AppliedType(tycon: TypeRef, _) if tycon.symbol.isClass =>
tp
case tp @ AppliedType(tycon: TypeRef, targs) if tycon.symbol.isClass =>
/* The theory says we should just return `tp` here. However, due to how
* baseType works (called from `isBaseTypeWithDisjointArguments`),
* it can create infinitely growing towers of `AnnotatedType`s. This
* defeats the infinite recursion detection with the `pending` set.
* Therefore, we eagerly remove all non-refining annotations. We are
* allowed to do that because they don't affect subtyping (so cannot
* create an ill-kinded `AppliedType`) and would anyway be stripped
* later on by the recursive calls to `provablyDisjoint`, though
* `disjointnessBoundary`).
* See tests/pos/provably-disjoint-infinite-recursion-1.scala for an example.
*/
tp.derivedAppliedType(
tycon,
targs.mapConserve(_.stripAnnots(keep = _.symbol.derivesFrom(defn.RefiningAnnotationClass)))
)
Copy link
Contributor

@olhotak olhotak Mar 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sjrd Is it supposed to be possible for the targs to be LazyRefs? If they are, the pending set would also fail since LazyRefs compare using reference equality. We could call stripLazyRef here.

I have LazyRefs showing up in a modified version of the compiler in an example with F-bounds, but I don't have a self-contained test case that would make them show up in the unmodified compiler. If it is indeed possible for them to show up, would you have any hints on constructing a test case? In general I have difficulty constructing test cases that even trigger provablyDisjoint to be called on a desired pair of types.

case tp: TermRef =>
val isEnumValue = tp.termSymbol.isAllOf(EnumCase, butNot = JavaDefined)
if isEnumValue then tp
Expand Down
4 changes: 4 additions & 0 deletions tests/pos/provably-disjoint-infinite-recursion-1.scala
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
class Test {
def isTraversableAgain(from: Iterator[Int]): Boolean =
from.isInstanceOf[Iterable[?]]
}
10 changes: 10 additions & 0 deletions tests/pos/provably-disjoint-infinite-recursion-2.scala
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
type Tupled[A] <: Tuple = A match
case Tuple => A & Tuple
case _ => A *: EmptyTuple

enum Day:
case Saturday, Sunday

type Foo = Tupled[Day]

def foo(): Foo = Day.Saturday *: EmptyTuple