Assertion error when compiling config files in resident mode. #34

Closed
odersky opened this Issue Mar 3, 2014 · 2 comments

2 participants

@odersky

using this command in directory src/dotty/tools/dotc:

scala dotty.tools.dotc.Bench #runs 2 config/Properties.scala config/PathResolver.scala

We get an assertion error on the second run. here's the full output:

max constraint = Constraint(
uninstVars = String';
constrained types = Ascala.collection.immutable.List[A],
A1 >: String'Boolean
;
constraint =
A
A1 >: String'
)
time elapsed: 2176ms
assertion failure for >: String <: String <:< A, frozen = false
: String <: String is a class dotty.tools.dotc.core.Types$CachedTypeBounds
polyparam A found in AArrowAssoc[A]
assertion failure for (self: A)ArrowAssoc[A] <:< >: String <: String ?=>? >: String <: String, frozen = false
(self: A)ArrowAssoc[A] is a class dotty.tools.dotc.core.Types$CachedMethodType
: String <: String ?=>? >: String <: String is a class dotty.tools.dotc.typer.Inferencing$CachedViewProto
exception occured while typechecking dotc/config/PathResolver.scala
java.lang.AssertionError: assertion failed
at scala.Predef$.assert(Predef.scala:151)
at dotty.tools.dotc.core.Types$TypeBounds.(Types.scala:1870)
at dotty.tools.dotc.core.Types$CachedTypeBounds.(Types.scala:1962)
at dotty.tools.dotc.core.Uniques$TypeBoundsUniques.newBounds$1(Uniques.scala:84)
at dotty.tools.dotc.core.Uniques$TypeBoundsUniques.enterIfNew(Uniques.scala:90)
at dotty.tools.dotc.core.Types$TypeBounds$.apply(Types.scala:1978)`

@odersky odersky added a commit to odersky/dotty that referenced this issue Mar 3, 2014
@odersky odersky Add test case for #34
Right now this one fails.
f0d5662
@odersky odersky added a commit to odersky/dotty that referenced this issue Mar 3, 2014
@odersky odersky Fix of #34
The root cause of #34 was that we took a type argument which was an existential type. These are returned as type bounds, which make no sense in the calling context. To avoid that problem in the future, `typeArgs`
got renamed to `argInfos`, so it is clear we get an info, not necessarily a value type. There are
also added method `argTypes`, `argTypesLo`, `argTypesHi`, which return a type, but either throw an exception or return a lower/upper approximation of the argument is an existential type.

There's another issue that the existential type only arose when compiling the same couple fo files the seciond time. We need to chase that one down separately.
f3dacf9
@odersky

The build passes, but I leave the issue open because we still have to find out why the problem arises only during 2nd run, and how it depends on file order.

@smarter
Programming Methods Laboratory EPFL member

Looks like it works now.

@smarter smarter closed this Nov 18, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment