Extend pattern type constraining to sealed hierarchies

[dwijnand]

Fixes #4790
Adds sealed to case, where #14820 looked to handle all classes.

Require sealed traits to be extended invariantly.

[abgruszecki]

OK, so if I understand this correctly, after this PR sealed trait-s will also require themselves to be extended invariantly. At first glance, everything looks like it works, though I'll need to spend a bit more time thinking about it, before the end of this week.

I think we should have more tests too, for instance ones that show Guillaume's examples from here #16885 (comment) do not work anymore. Also, it's not clear to me if this example should compile, FB should be rejected since I don't think it's possible to create an instance of it :

scala> object O {
     |   sealed trait Foo[+A] {
     |     def foo: A
     |   }
     | 
     |   sealed trait Bar[+A] extends Foo[A] {
     |     def bar: A
     |   }
     | 
     |   sealed trait FB extends Bar[Any] with Foo[Int] {
     |     def bar: Any = ""
     |     def foo: Int = 1
     |   }
     | }
// defined object O

Last thing: the impact of changing how sealed trait-s work looks reasonable to me, but it will have to be discussed with Martin.

[dwijnand]

I think we should have more tests too, for instance ones that show Guillaume's examples from here #16885 (comment) do not work anymore.

Sure, no problem.

Also, it's not clear to me if this example should compile, FB should be rejected since I don't think it's possible to create an instance of it

It isn't necessary to forbid that, is it? I assume there are other cases like that - but perhaps not.

[abgruszecki]

Also, it's not clear to me if this example should compile, FB should be rejected since I don't think it's possible to create an instance of it

It isn't necessary to forbid that, is it? I assume there are other cases like that - but perhaps not.

It's not necessary, but FB already inherits from Foo in two different conflicting ways. If the trait can't be instantiated we should emit an error when it is defined, not when we try to extend it.

[abgruszecki]

Ok, so it's really not looking like I will have any time to experiment with this branch and see what the code is actually doing. As far as I can tell, there are two approaches here:

1) Require sealed traits to be extended invariantly

This is effectively what the changes to RefChecks implement, as far as I can tell. Previously only case classes had this restriction, and it was implemented IIUC because it was seen as very strange to extend a case class. Extending the restriction to sealed traits does feel reasonable to me, but you will need to come up with a justification as to why it won't break too much code.

Also, if this is what you intend to do, then refinementIsInvariantCls is too complicated. It'd be enough to check if cls is sealed.

2) Check sealed traits for being effectively extended invariantly

This seems to be what you're trying to do in refinementIsInvariantCls. In this approach, we have special reasoning for sealed traits that are only extended by case and final classes. This is as though we had "invariant refinement" that Guillaume mentioned here, but it was only inferred in particular positions: for type arguments of case classes and type arguments of some sealed traits. Note that you need to be very careful with a check like this, because as Guillaume's example shows, it's enough to extend sealed trait Foo with sealed trait Bar so that it's possible to define a case class that extends Foo variantly. (In Guillaume's exmaple class FB isn't case, but it could be.)

If this is what you intend to do, then there should be no change to RefChecks; it'd be polite if you'd also come up with an explanation as to why the check is actually sound, and include the explanation in the PR.

Also, this is a very subtle change. I would expect to see multiple tests that exercise the change and show what does and what doesn't work, ideally closer to 5 tests rather than 1.