SI-8134 SI-5954 Fix companions in package object under separate comp.

The tests cases enclosed exhibited two failures modes under
separate compilation.

  1. When a synthetic companion object for a case- or implicit-class
     defined in a package object is called for,
     `Namer#ensureCompanionObject` is used to check for an explicitly
     defined companion before decided to create a synthetic one.
     This lookup of an existing companion symbol by `companionObjectOf`
     would locate a symbol backed by a class file which was in the
     scope of the enclosing package class. Furthermore, because the
     owner of that symbol is the package object class that has now
     been noted as corresponding to a source file in the current
     run, the class-file backed module symbol is *also* deemed to
     be from the current run. (This logic is in `Run#compiles`.)

     Thinking the companion module already existed, no synthetic
     module was created, which would lead to a crash in extension
     methods, which needs to add methods to it.

  2. In cases when the code explicitly contains the companion pair,
     we still ran into problems in the backend whereby the class-file
     based and source-file based symbols for the module ended up in
     the same scope (of the package class). This tripped an assertion
     in `Symbol#companionModule`.

We get into these problems because of the eager manner in which
class-file based package object are opened in `openPackageModule`.
The members of the module are copied into the scope of the enclosing
package:

    scala> ScalaPackage.info.member(nme.List)
    res0: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462

    scala> ScalaPackage.info.member(nme.PACKAGE).info.member(nme.List)
    res1: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462

This seems to require a two-pronged defense:

  1. When we attach a pre-existing symbol for a package object symbol
     to the tree of its new source, unlink the "forwarder" symbols
     (its decls from the enclosing
     package class.

  2. In `Flatten`, in the spirit of `replaceSymbolInCurrentScope`,
     remove static member modules from the scope of the enclosing
     package object (aka `exitingFlatten(nestedModule.owner)`).

This commit also removes the warnings about defining companions
in package objects and converts those neg tests to pos (with
-Xfatal-warnings to prove they are warning free.)

Defining nested classes/objects in package objects still has
a drawback: you can't shift a class from the package to the
package object, or vice versa, in a binary compatible manner,
because of the `package$` prefix on the flattened name of
nested classes. For this reason, the `-Xlint` warning about
this remains. This issue is tracked as SI-4344.

However, if one heeds this warning and incrementatlly recompiles,
we no longer need to run into a DoubleDefinition error (which
was dressed up with a more specific diagnostic in SI-5760.)
The neg test case for that bug has been converted to a pos.
SI-5954 Invalidate TypeRef cache when opening package object

I noticed that the pos/5954d was tripping a println "assertion".
This stemmed from an inconsistency between
`TypeRef#{parents, baseTypeSeq}` for a package objects compiled
from source that also has a class file from a previous compilation
run.

I've elevated the println to a devWarning, and changed
`updatePosFlags`, the home of this evil symbol overwriting,
to invalidate the caches in the symbols info. Yuck.

I believe that this symptom is peculiar to package objects because
of the way that the completer for packages calls `parents` during
the Namer phase for package objects, before we switch the symbol
to represent the package-object-from-source. But it seems prudent
to defensively invalidate the caches for any symbol that finds its
way into `updatePosFlags`.
SI-5954 Add a TODO comment with an idea for future work

As the prophet once said:

  "'Tis better to never do at all than to have do and undo"

Let's try that in 2.12.
SI-8134 Address pull request feedback

Aesthetics only.
SI-6736 Range.contains is wrong

Removed once-used private method that was calculating ranges in error and corrected the contains method (plus improved performance).
Reasonable Range operations consistently work when overfull.

Operations are reasonable when they don't require indexing or conversion into a collection.  These include head, tail, init, last, drop, take, dropWhile, takeWhile, dropRight, takeRight, span.

Tests added also to verify the new behavior.
SI-261 private vals in traits depend on composition order

Fix for SI-7475 in #3440 took care of this one.

I nixed the old (redundant) test cases and replaced by a single run/ test,
which didn't compile until.
SI-8263 Avoid SOE in logicallyEnclosingMember

We've started calling this method during higher-kinded subtyping
to ensure that variances of higher order type params in overriding
as soundly aligned.

Turns out that running this over the expansion of the SBT task
macro leads to a SOE due to a corrupt owner chain.

I've fixed that in SBT (https://github.com/sbt/sbt/pull/1113),
but we ought not crash like this.

This commit considers NoSymbol to be its own enclosing member and
logs a -Xdev warning. This is analagous to the handling of
`NoSymbol.owner`.
Merge pull request #3512 from adriaanm/t261

 private vals in traits depend on composition order
A test case for a name binding progression

I noticed the change when adapting Slick to work with
Scala 2.11 in `AbstractSourceCodeGenerator.scala`.
The behaviour changed in a70c8219.

This commit locks down the new, correct behaviour with a test.
Merge pull request #3437 from Ichoran/issue/6736

SI-6736 Range.contains is wrong
SI-8177 co-evolve more than just RefinedTypes

`asSeenFrom` produced a typeref of the shape `T'#A` where `A` referred to a symbol
defined in a `T` of times past.

More precisely, the `TypeRef` case of `TypeMap`'s `mapOver` correctly modified a prefix
from having an underlying type of `{ type A = AIn }` to `{ type A = Int }`,
with a new symbol for `A` (now with info `Int`), but the symbol in the outer
`TypeRef` wasn't co-evolved (so it still referred to the `A` in `{ type A = AIn }`
underlying the old prefix).

`coEvolveSym` used to only look at prefixes that were directly `RefinedType`s,
but this bug shows they could also be `SingleType`s with an underlying `RefinedType`.
Merge pull request #3506 from retronym/topic/logically-no-symbol

 Avoid SOE in logicallyEnclosingMember
Merge pull request #3515 from retronym/topic/stable-ident-ambiguous

A test case for a name binding progression
SI-8177 refine embeddedSymbols

We look for any prefix that has a refinement class for a type symbol.
This includes ThisTypes, which were not considered before.

pos/t8177g.scala, neg/t0764*scala now compile, as they should

Additional test cases contributed by Jason & Paul.
Merge pull request #3516 from adriaanm/t8177

 SI-8177 co-evolve more than just RefinedTypes
SI-7753 InstantiateDependentMap narrows type of unstable args

[Most of this comment and the initial fix were implemented by Jason Zaugg.
I just cleaned it up a bit.]

After a soundness fix in SI-3873, instantiation of dependent
method type results behaved differently depending on whether the argument
from which we were propagating information had a stable type
or not. This is particular to substitution into singleton types
over the parameter in question.

If the argument was stable, it was substituted into singleton
types, such as the one below in the prefix in `a.type#B`
(which is the longhand version of `a.B`)

  scala> class A { type B >: Null <: AnyRef }
  defined class A

  scala> object AA extends A { type B = String }
  defined object AA

  scala> def foo(a: A): a.B = null
  foo: (a: A)a.B

  scala> foo(AA)
  res0: AA.B = null

But what if it isn't stable?

  scala> foo({def a = AA; a: A { type B <: String}})
  res1: a.B = null

This commit changes that to:

  scala> foo({def a = AA; a: A { type B <: String}})
  res1: A{type B <: String}#B = null
SI-8244 Fix raw type regression under separate compilation

In #1901, handling of raw types encountered in signatures during class
file parsing was changed to work in the same manner as
`classExistentialType`, by using
`existentialAbstraction(cls.tparms, cls.tpe_*)`

But this never creates fresh existential symbols, and just sticks
the class type parameters it `quantified`:

	scala> trait T[A <: String]
	defined trait T

	scala> val cls = typeOf[T[_]].typeSymbol
	cls = trait T#101864

	scala> cls.typeParams
	res0 = List(type A#101865)

	scala> cls.tpe_*
	res1 = T#101864[A#101865]

	scala> classExistentialType(cls)
	res3 = T#101864[_ <: String#7209]

	scala> val ExistentialType(quantified, result) = res3
	List(type A#101865)

In the enclosed test case, this class type parameter was substituted
during `typeOf[X] memberType sym`, which led us unsoundly thinking
that `Raw[_]` was `Raw[X]`.

I've added a TODO comment to review the other usages of
`classExistentialType`.

Test variations include joint and separate compilation, and the
corresponding Scala-only code. All fail with type errors now,
as we expect. I've also added a distillation of a bootstrap
error that failed when I forgot to wrap the `existentialType`.
SI-8153 Mutation is hard, let's go shopping with an empty list

Changed the implementation of iterator to be more robust to mutation of the underlying ListBuffer.

Added a test to make sure bug is gone.

Fixed an "unsafe" usage of ListBuffer.iterator in the compiler, and added a comment explaining the (new) policy for iterating over a changing ListBuffer.

The compiler now uses a synchronized-wrapped ArrayBuffer instead of ListBuffer, as that makes the (custom) units Iterator more natural to write (and avoids O(n) lookups).
Merge pull request #3518 from adriaanm/t7753

SI-7753 InstantiateDependentMap narrows type of unstable args