Fix #1751: Make dominator work after erasure

[odersky]

i1751.scala shows a case where we need to compute the approximation
of an or-type during erasure. This can lead to an empty set of common
classes because Any does not exist anymore after erasure.

Review by @liufengyun ?

[DarkDimius]

Our of curiosity: where do we construct an Or type during erasure?

[odersky]

Our of curiosity: where do we construct an Or type during erasure?

We don't (in this case), actually.It's a type that was left in the unerased tree. The error happens with the third line below in the stacktrace:

override def typedApply(tree: untpd.Apply, pt: Type)(implicit ctx: Context): Tree = {
  val Apply(fun, args) = tree
  if (fun.symbol == defn.dummyApply)

As you can see, it takes the symbol of the previous unerased tree.

[odersky]

Also relevant is the comment on this Config variable:

/** Check that certain types cannot be created in erasedTypes phases.
 *  Note: Turning this option on will get some false negatives, since it is
 *  possible that And/Or types are still created during erasure as the result
 *  of some operation on an existing type.
 */
final val checkUnerased = false

[liufengyun]

@odersky It looks good to me. Following minimised version of test is more intuitive:

object Test {
  def f(x: Int) = if (x > 0) -1 else "String"

  def h = f(3) == 22      //  `== ` triggers the exception
}