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

Compiler crash inferring higher-kinded type from expected type with refinement #9361

Closed
scabug opened this Issue Jun 20, 2015 · 8 comments

Comments

Projects
None yet
2 participants
@scabug
Copy link

scabug commented Jun 20, 2015

The following will evince the compiler crash:

abstract class Foo[Tc[_]] { def tc: Tc[_] }
object Foo {
  def foo[Tc[_]](): Foo[Tc] { type T = Nothing } =
    new Foo { def tc = null.asInstanceOf[Tc[_]] }
}

It appears that in the absence of a type parameter to the new Foo instantiation, the type inferencer looks to the expected type of foo to try to infer it. In the presence of the type refinement in the expected type, this crashes the compiler.

This doesn't crash in Scala 2.10.6 (although it doesn't compile), but does with every version from a random sample of 2.11.x releases.

Could be related to #2712.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Jun 20, 2015

Imported From: https://issues.scala-lang.org/browse/SI-9361?orig=1
Reporter: @propensive
Affected Versions: 2.11.6
See #2712

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Jun 26, 2015

@retronym said:
This regressed in https://github.com/scala/scala/pull/1564/files

I actually spotted one "non refactoring" amongst that patch when I originally reviewed it. The discussion seems to be lost in the ashes of paulp/scala, but I found this in my email:

With the current typer, they're the same thing. In some hypothetical future typer which doesn't mutate everything in place, only whereClauses1 is correct, because those are the trees which were just typed by typedStats. In principle they might not even be the same trees, although I don't think anyone is planning on a change like that.

I reverted that change and it doesn't fix the crash. So there must be another needle hidden in that haystack.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Jun 26, 2015

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Jun 26, 2015

@retronym said (edited on Jun 26, 2015 4:48:46 AM UTC):
Here's the introduction of foundType to improve the error messages:

scala/scala@05382e2

This seemingly was "refactored" out of use in:

scala/scala@c800d1f#diff-05c273d837c49f8b6278b19592a541beR147

Although the end result was still the same, thanks to the way the code was just mutating the access modifiers of members in the anonymous class.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Jun 26, 2015

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Jul 3, 2015

@propensive said:
Based on the stack trace when the compiler crashes, I think I've stumbled across this same bug again, twice in a fortnight (on different projects). Common factor: me.

Here's a different, more complex (but still not easy to reduce much further) test case:

object Test {
  trait Foo {
    type Inner
    type Result = Ordering[Inner] // any invariant type constructor
    def get: Result
  }  

  trait Super
  trait Bar[T] extends Super { type Result = T }

  def wrap[V <: Super](v: V): Foo { type Inner = this.type with v.type } = ???
  
  val baz: Bar[_] = ???
  wrap(baz).get: Ordering[Foo { type Result = this.type }]
}

This version does appear to crash every version of the compiler between 2.10.3 and 2.12.0-M1.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented May 14, 2016

@milessabin said:
[~propensive]'s example appears to be different ... it's not tripping the same (or indeed, any) assert as the one tripped by the example in the description of this ticket.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented May 14, 2016

@milessabin said:
PR here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment