Minimal support for dependent case classes

[smarter]

This lets us write:

    trait A:
      type B

    case class CC(a: A, b: a.B)

Pattern matching works but isn't dependent yet:

    x match
      case CC(a, b) =>
        val a1: A = a
        // Dependent pattern matching is not currently supported
        // val b1: a1.B = b
        val b1 = b // Type is CC#a.B

(for my usecase this isn't a problem, I'm working on a type constraint API which lets me write things like case class CC(a: Int, b: Int GreaterThan[a.type]))

Because case class pattern matching relies on the product selectors _N, making it dependent is a bit tricky, currently we generate:

    case class CC(a: A, b: a.B):
      def _1: A = a
      def _2: a.B = b

So the type of _2 is not obviously related to the type of _1, we probably need to change what we generate into:

    case class CC(a: A, b: a.B):
      @uncheckedStable def _1: a.type = a
      def _2: _1.B = b

But this can be done in a separate PR.

Fixes #8073.

[noti0na1]

I am doing some experiment with dependent pattern match in CC, and this PR is useful for me as well!

I modified the desuger so _1, _2, etc will have better types: always use singleton types when the field is not var. I haven't finished because I also need to modify the typer so the selections in the cases are binded to something.

[smarter]

@noti0na1 Awesome! Let me know how it goes.

[odersky]

I think it's probably better to wait after the cutoff with this?

[smarter]

So 3.6.1 rather than 3.6.0?

[odersky]

Yes, 3.6.1 should work OK.

[odersky]

AFAICS this only touches the fromProduct method. So it would be good to clarify some more what the limitations are. You mention dependent pattern matching. Ae there other things that don't work as one would expect?

But anyway this change in isolation LGTM

[sjrd]

Will we be able to ever fix the remaining things without breaking binary/TASTy compat in the future?

Currently we're safe because the definition does not compile. But if we make it compile today with incorrect code for some methods, we might be stuck with those incorrect definitions forever.

[noti0na1]

Hi @smarter , is there any plan to merge this?

[smarter]

@noti0na1 I wanted to look into combining this with #21828 to future-proof it, but I haven't had the time to do that yet.

[noti0na1]

I wanted to look into combining this with #21828 to future-proof it

I don't have more progress on #21828 right now😢

There are still many things broken, and I'm also worry about binary compatibility.

[sjrd]

Core Meeting says let's go ahead with this as is.

@smarter Could you rebase on the latest main to get a recent CI run?

[odersky]

Looks like there is an bad interaction with @unroll which needs to be investigated.

[smarter]

Looks like the unroll phase assumes a specific shape for the fromProduct method:

scala3/compiler/src/dotty/tools/dotc/transform/UnrollDefinitions.scala

Line 239 in 705e10e

val Apply(select, args) = defdef.rhs: @unchecked

It already crashes if I define fromProduct manually with braces:

case class Foo(x: String, @unroll y: Int = 1)
object Foo:
  def fromProduct(x: Product): Foo = {
    new Foo(
      x.productElement(0).asInstanceOf[String],
      x.productElement(1).asInstanceOf[Int]
    )
  }

@bishabosha instead of transforming the body of fromProduct, couldn't we directly define the unroll-friendly version of fromProduct in SyntheticMembers ?

[bishabosha]

instead of transforming the body of fromProduct, couldn't we directly define the unroll-friendly version of fromProduct in SyntheticMembers ?

It should work but probably worth checking that these are still generated after we detect unroll annotations on parameters (which updates the compilation unit flag)

But it might be simpler to detect user defined method if the goal is to 'not crash'?
Edit: i see now that this is about compiler generated code crashing

so yeah architecture is in PostTyper we scan parameters for unroll, which updates a field in CompilationUnit, you can probably check for that in SyntheticMembers - then remove the special handling in Unroll phase which would simplify that a bunch.

[bishabosha]

.asInstanceOf[Seq[String]]

[bishabosha]

this should be dead code now i think

[smarter]

oops, I forgot the auto-merge was on, can you double-check the changes related to unroll @bishabosha ?

[bishabosha]

@smarter seems good - the test case for illegal unroll on fromProduct is here https://github.com/scala/scala3/blob/main/tests/neg/unroll-duped.scala, so it seems no behavior change