Harden type checking for enum values

[liufengyun]

This is a follow-up of #11327.

We cannot generalize further without complications:

val b = 'b'

56 match
case 'a' =>
case `b` =>

[liufengyun]

The change detects a possible error in the following code:

https://github.com/lampepfl/dotty/blob/05e5eabfd613f1ad72ee760c112f6a13813b15f5/scaladoc/src/dotty/tools/scaladoc/translators/ScalaSignatureProvider.scala#L25-L26

Error:  -- [E007] Type Mismatch Error: /__w/dotty/dotty/scaladoc/src/dotty/tools/scaladoc/translators/ScalaSignatureProvider.scala:25:27 
Error:  25 |      case Kind.Given(Kind.Val, _, _) =>
Error:     |                      ^^^^^^^^
Error:     |Found:    (dotty.tools.scaladoc.Kind.Val : dotty.tools.scaladoc.Kind)
Error:     |Required: dotty.tools.scaladoc.Kind.Def | dotty.tools.scaladoc.Kind.Class
Error:     |pattern type is incompatible with expected type

[smarter]

Why is this change needed?

[michelou]

@liufengyun Here, I was asking myself the same question !

[liufengyun]

Good question. We need to widen the scrutinee type instead.

[liufengyun]

Actually, we have the following error without the change:

-- [E007] Type Mismatch Error: tests/run/option-extract.scala:10:11 ----------------------------------------------------
10 |      case None => default
   |           ^^^^
   |           Found:    (Option.None : Option[Nothing])
   |           Required: Any{ExtractResult = LazyRef([B] =>> (=> B) => B)} & Option[A]
   |           pattern type is incompatible with expected type

This seems to be a subtle interaction with opaque types in subtype checking.

[liufengyun]

I tried to play with the opaque types with the following change:

--- a/compiler/src/dotty/tools/dotc/core/Types.scala
+++ b/compiler/src/dotty/tools/dotc/core/Types.scala
@@ -4548,6 +4548,7 @@ object Types {

     private var selfTypeCache: Type = null
     private var appliedRefCache: Type = null
+    private var selfTypeWithoutOpaqueCache: Type = null

     /** The self type of a class is the conjunction of
      *   - the explicit self type if given (or the info of a given self symbol), and
@@ -4566,6 +4567,23 @@ object Types {
       selfTypeCache
     }

+    /** The self type without opaque members refinements */
+    def selfTypeWithoutOpaque(using Context): Type = {
+      def dropRefinement(tp: Type): Type = tp match
+        case RefinedType(parent, _, _: TypeAlias) =>
+          // TODO: maybe strengthen the check for Opaque flag
+          parent
+        case AndType(tp1, tp2) =>
+          dropRefinement(tp1) & dropRefinement(tp2)
+        case _ =>
+          tp
+      end dropRefinement
+
+      if selfTypeWithoutOpaqueCache == null then
+        selfTypeWithoutOpaqueCache = dropRefinement(selfType)
+      selfTypeWithoutOpaqueCache
+    }

But found no place where we could sensibly use selfTypeWithoutOpaque in the code.

[smarter]

Currently, the refinemen is stripped in widening, and kept in member selection. What cases you have mind that this PR will be a problem?

I don't know, but I see things the other way around: we shouldn't do more stripping than we need to, and we shouldn't special-case opaque types more than we have to.

The example you posted above is another orthogonal issue --- it comes from the fact that we always widen the scrutinee in exhaustivity check.

I believe the following should also compile without warnings:

trait Mixin

sealed trait Foo { self: Mixin =>
  def foo = this match {
    case _: Foo =>
  }
}

It really seems that the cleanest fix for this sort of issues is for the exhaustiveness checker to always strip self types.

[liufengyun]

I kind of agree that stripping of opaque refinements should be avoided if possible. Among the following 3 choices:

1. Close this PR and revert Fix #9740: harden type checking for pattern match on objects #11327 for consistency
2. Keep this PR w/o stripping and change the test case tests/run/option-extract.scala with (this: Option[A])
3. Keep this PR with stripping

Maybe the 2nd is a good compromise?

BTW, this PR and #11327 are not fixing any existing issues. They intend to harden type checking and align with Scala 2 behavoir in type checking patterns.

[smarter]

Maybe the 2nd is a good compromise?

I'm fine with that if we also open an issue to keep track of the issue with the exhaustivity checker.

[liufengyun]

I'm fine with that if we also open an issue to keep track of the issue with the exhaustivity checker.

Agreed. I'll create an issue for the test tests/run/option-extract.scala (it's a typing error, not an exhaustivity warning).

[liufengyun]

The last commit removed and we created an issue #11669 for tests/run/option-extract.scala.