Imported From: https://issues.scala-lang.org/browse/SI-4305?orig=1
Reporter: @paulp

@paulp said:
As of r24437 (don't know how far back it goes) this hits if you try to compile the collections.

% scalac29 `find /scala/trunk/src/library/scala/collection -name '*.scala'`
error: java.lang.Error: A in trait TraversableViewLike cannot be instantiated from [+A,+Coll,+This <: scala.collection.TraversableView[A,Coll] with scala.collection.TraversableViewLike[A,Coll,This]]scala.collection.TraversableViewLike[A,Coll,This]
	at scala.tools.nsc.symtab.SymbolTable.abort(SymbolTable.scala:35)
	at scala.tools.nsc.symtab.Types$$AsSeenFromMap.throwError$$1(Types.scala:3389)
	at scala.tools.nsc.symtab.Types$$AsSeenFromMap.instParam$$1(Types.scala:3392)
	at scala.tools.nsc.symtab.Types$$AsSeenFromMap.toInstance$$1(Types.scala:3403)
	at scala.tools.nsc.symtab.Types$$AsSeenFromMap.apply(Types.scala:3419)
	at scala.tools.nsc.symtab.Types$$AsSeenFromMap.apply(Types.scala:3289)
	at scala.tools.nsc.symtab.Types$$TypeMap$$$$anonfun$$mapOverArgs$$1.apply(Types.scala:3114)
	at scala.tools.nsc.symtab.Types$$TypeMap$$$$anonfun$$mapOverArgs$$1.apply(Types.scala:3110)
	at scala.tools.nsc.symtab.Types$$class.map2Conserve(Types.scala:4886)
	at scala.tools.nsc.symtab.SymbolTable.map2Conserve(SymbolTable.scala:13)

@paulp said:
Reduced and clarified: this has remained hidden because it is order dependent.

# compiles this way 
% scalac29 src/library/scala/collection/SeqViewLike.scala src/library/scala/collection/immutable/StreamViewLike.scala
# not this way
% scalac29 src/library/scala/collection/immutable/StreamViewLike.scala src/library/scala/collection/SeqViewLike.scala
error: java.lang.Error: A in trait TraversableViewLike cannot be instantiated from [+A,+Coll,+This <: scala.collection.TraversableView[A,Coll] with scala.collection.TraversableViewLike[A,Coll,This]]scala.collection.TraversableViewLike[A,Coll,This]
	at scala.tools.nsc.symtab.SymbolTable.abort(SymbolTable.scala:35)
	at scala.tools.nsc.symtab.Types$$AsSeenFromMap.throwError$$1(Types.scala:3389)
	at scala.tools.nsc.symtab.Types$$AsSeenFromMap.instParam$$1(Types.scala:3392)
	at scala.tools.nsc.symtab.Types$$AsSeenFromMap.toInstance$$1(Types.scala:3403)
	at scala.tools.nsc.symtab.Types$$AsSeenFromMap.apply(Types.scala:3419)
	at scala.tools.nsc.symtab.Types$$AsSeenFromMap.apply(Types.scala:3289)
	at scala.tools.nsc.symtab.Types$$TypeMap$$$$anonfun$$mapOverArgs$$1.apply(Types.scala:3114)

I am going to kick this up to high for now because these source file order dependent bugs are maddening so if something can be done in the short term it would be great, but if someone wants to de-high it I won't complain.

@adriaanm said:
unfortunately I don't think this has an easy fix (the full fix: load types a little more eagerly so we always have the full type param info, get rid of unsafeTypeParams, and allow a PolyType's resulttype to be completed lazily)

a stopgap fix could be to add a sym.info in a strategic location, but I'm not sure we should be doing that right now -- in any case, I'd prefer to delay working on this until I can fix it properly

@adriaanm said:
Replying to [comment:6 moors]:

unfortunately I don't think this has an easy fix (the full fix: load types a little more eagerly so we always have the full type param info, get rid of unsafeTypeParams, and allow a PolyType's resulttype to be completed lazily)

a stopgap fix could be to add a sym.info in a strategic location, but I'm not sure we should be doing that right now -- in any case, I'd prefer to delay working on this until I can fix it properly
thinking about this some more (I should probably do that before commenting at all): I'm not sure anymore this is related to unsafeTypeParams, although other compilation-order dependent bugs I've seen before (#4070) are

@paulp said:
OK, I'm turning off the air raid siren, now it's just making it's usual bloop bloop bloop sound.

@adriaanm said:
the classOf[C] thingy was due to asSeenFrom not dealing directly with class-constants. see adriaanm/scala@86c59b5

the compilation order dependent problem with collections can be reduced to (minimally):

// 1.scala
trait Derived[+SA, +This <: Derived[SA, This]] extends Base[SA, This] {
  trait Reversed extends super.Reversed with super.Transformed[SA]
  protected override def newReversed: super.Transformed[SA] = new Reversed { } 
}

// 2.scala
trait Base[+A, +This <: Base[A, This]] {
  trait Transformed[+B] {
    override def toString: String = error("")
  }
  
  trait Reversed extends Transformed[A] {
    private def x: Unit = {x: A => error("") }
  }

  protected def newReversed: Transformed[A] = new Reversed { }
}

@adriaanm said:
the error occurs when getting the memberInfo of the symbol constructor $$anonfun$$x$$1 with info (arg$$outer: Reversed$$class.this.type)scala.runtime.AbstractFunction1[A,Nothing] with Serializable{final def apply(v1: java.lang.Object): java.lang.Object}

A in trait Base cannot be instantiated from [+A,+This <: Base[A,This]]Base[A,This]

so the question is: why is baseType returning a PolyType here!?

@adriaanm said:
I think the problem is a bad interaction of caching, atPhase(erasure), and erased types mistakingly being treated as type constructors when they re-appear in an atPhase(erasure) that happens after erasure. I don't understand when PolyTypes are expected in BaseTypeSeqs and when they aren't, so I don't know how to fix this. I've spent the one day I was willing to spend on this.

since the error occurs late in the game and generic signatures are not absolutely crucial, I'd suggest a temporary cop out: catch the exception thrown by memberInfo in addGenericSignature in GenJVM

test cases and "fix" that makes me cringe in commit adriaanm/scala@1cac127

Paul, could you please take it from here?

@paulp said:
Replying to [comment:13 moors]:

Paul, could you please take it from here?

You got it. Thanks for giving us a whole day of your precious time! (I'm just kidding, your time's not that precious.)

@paulp said:
(In r24511) Fix for crasher with Class objects. Code by moors, comment by
extempore. References #4305, no review.

@paulp said:
Let's call this fixed with that commit and I opened #4365 for the rest.