Skip to content

Abstract type member on object inconsistent compilation error #15931

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

Closed
Lasering opened this issue Aug 28, 2022 · 1 comment · Fixed by #15959
Closed

Abstract type member on object inconsistent compilation error #15931

Lasering opened this issue Aug 28, 2022 · 1 comment · Fixed by #15959

Comments

@Lasering
Copy link

Lasering commented Aug 28, 2022

Compiler version

3.1.3

Minimized code

sealed trait TP:
  type P

final class Foo extends TP:
  enum P:
    case A, B

object Bar extends TP:
  enum P:
    case A, B, C

// Works
summon[Foo#P <:< TP#P]
val a: TP#P = Foo().P.A

// These fail
summon[Bar.type#P <:< TP#P]
summon[Bar.P <:< TP#P]
val b: TP#P = Bar.P.A

Output

-- Error: -----------------------------------------------------------------------------------------------------------------------------------------------------
17 |summon[Bar.type#P <:< TP#P]
   |                           ^
   |                           Cannot prove that Bar.P <:< TP#P.
-- Error: -----------------------------------------------------------------------------------------------------------------------------------------------------
18 |summon[Bar.P <:< TP#P]
   |                      ^
   |                      Cannot prove that Bar.P <:< TP#P.
-- [E007] Type Mismatch Error: --------------------------------------------------------------------------------------------------------------------------------
19 |val b: TP#P = Bar.P.A
   |              ^^^^^^^
   |              Found:    (Bar.P.A : Bar.P)
   |              Required: TP#P²
   |
   |              where:    P  is a class in object Bar
   |                        P² is a type in trait TP

Expectation

Code should compile.

Scastie link
Discussion at Discord channel

Context

Regardless of the concrete instance of TP I want to:

  • be able to have a value of type TP#P
  • have a function receiving an argument of type TP#P and be able to pass it either an instance of Foo.P or Bar.type.P.
@Lasering Lasering added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Aug 28, 2022
@Kordyjan Kordyjan added area:typer area:enums and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Aug 29, 2022
@Kordyjan
Copy link
Contributor

The same (wrong) behavior is present in 3.1.3, 3.2.0-RC4 and 3.2.1-RC1-bin-20220828-8a7c84c-NIGHTLY.

I tried to use --explain to get why the last assignment is failing and I got:

   | Tree: Bar.P.A
   | I tried to show that
   |   (Bar.P.A : Bar.P)
   | conforms to
   |   TP#P
   | but the comparison trace ended with `false`:
   |
   |   ==> (Bar.P.A : Bar.P)  <:  TP#P
   |     ==> Bar.P  <:  TP#P (left is approximated)
   |     <== Bar.P  <:  TP#P (left is approximated) = false
   |   <== (Bar.P.A : Bar.P)  <:  TP#P = false
   |
   | The tests were made under a constraint with:
   |  uninstantiated variables: A
   |  constrained types: [A] => A =:= A
   |  bounds:
   |      A >: Foo#P <: TP#P
   |  ordering:

A >: Foo#P <: TP#P Part is interesting here.

odersky added a commit to dotty-staging/dotty that referenced this issue Sep 3, 2022
odersky added a commit that referenced this issue Sep 12, 2022
Fixes #15931

This also fixes #8338, which was mis-classified as a neg test before.
mpollmeier pushed a commit to mpollmeier/dotty that referenced this issue Oct 16, 2022
@Kordyjan Kordyjan added this to the 3.2.2 milestone Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants