And, Or take sets of Props
Remove redundant UniqueSym class.
Debug printing for Any, not AnyRef, to include primitives

Signed-off-by: Gerard Basler <gerard.basler@gmail.com>
Avoid the `CNF budget exceeded` exception via smarter translation into CNF.

The exhaustivity checks in the pattern matcher build a propositional
formula that must be converted into conjunctive normal form (CNF) in
order to be amenable to the following DPLL decision procedure.
However, the simple conversion into CNF via negation normal form and
Shannon expansion that was used has exponential worst-case complexity
and thus even simple problems could become untractable.

A better approach is to use a transformation into an _equisatisfiable_
CNF-formula (by generating auxiliary variables) that runs with linear
complexity. The commonly known Tseitin transformation uses bi-
implication. I have choosen for an enhancement: the Plaisted
transformation which uses implication only, thus the resulting CNF
formula has (on average) only half of the clauses of a Tseitin
transformation.

The Plaisted transformation uses the polarities of sub-expressions to
figure out which part of the bi-implication can be omitted. However,
if all sub-expressions have positive polarity (e.g., after
transformation into negation normal form) then the conversion is
rather simple and the pseudo-normalization via NNF increases chances
only one side of the bi-implication is needed.

I implemented only optimizations that had a substantial
effect on formula size:
- formula simplification, extraction of multi argument operands
- if a formula is already in CNF then the Tseitin/Plaisted
  transformation is omitted
- Plaisted via NNF
- omitted: (sharing of sub-formulas is also not implemented)
- omitted: (clause subsumption)
SI-8981 Tweak REPL help

Tweak colon command processing.

Fixes an unhelpful message about the ambiguity of colon.
SI-8970  hashCode of BigDecimal and Double do not match

Switched isValidDouble (binary equivalence) to isDecimalDouble (decimal expansion equivalence), as people generally do not care about the slew of extra decimal digits off the end of the binary approximation to a decimal fraction (decimal equivalence is the standard now).

Added minimal unit test to verify behavior.
SI-8783  MultiMap documentation for addBinding is incorrect

Fixed documentation to state that addBinding will not replace a `value` that is equal (according to ==).
SI-8951  SeqView and StreamView stack-overflow on negative index after flatMap

Checks and throws IndexOutOfBounds now.

No test, caught and checked by scala-collections-laws (line 405 presently).
SI-6519  PagedSeq is not lazy enough

This was actually an issue with `length` of all things--it wasn't stopping scanning when it was past the end of what was requested.  It'd just gratuitously read everything.

Also fixed an overflow bug with isDefinedAt along the way (start + index > Int.MaxValue would always return true despite never working).
spec: Add a link to the sources from the main page
SI-9003 Eagerly capture more potentially mutable binders

This is a re-run of SI-5158 in two different contexts.

As reported, the result of `unapply[Seq]` under name based pattern
matching might not guarantee stability of results of calls to
`_1`, `apply(i)`, etc, so we call these eagerly, and call them
once only.

I also found a case in regular pattern matching that we hadn't
accounted for: extracting elements of sequences (either from
a case class or from an `unapplySeq`) may also be unstable.

This commit changes `ExtractorTreeMaker` to force storage
of such binders, even under `-optimize`. This parallels the change
to `ProductExtractorTreeMaker` in 8ebe8e3e8.

I have added a special case for traditional `unapply` methods
returning `Option`. This avoids a change for:

```
% cat test/files/run/t9003b.scala
object Single {
  def unapply(a: Any) = Some("")
}

object Test {
  def main(args: Array[String]): Unit = {
    "" match {
      case Single(x) =>
        (x, x)
    }
  }
}
% qscalac -optimize -Xprint:patmat test/files/run/t9003b.scala 2>&1 | grep --context=5 get
      case <synthetic> val x1: Any = "";
      case5(){
        <synthetic> val o7: Some[String] = Single.unapply(x1);
        if (o7.isEmpty.unary_!)
          matchEnd4({
            scala.Tuple2.apply[String, String](o7.get, o7.get);
            ()
          })
        else
          case6()
      };
% scalac-hash v2.11.4 -optimize -Xprint:patmat test/files/run/t9003b.scala 2>&1 | grep --context=5 get
      case <synthetic> val x1: Any = "";
      case5(){
        <synthetic> val o7: Some[String] = Single.unapply(x1);
        if (o7.isEmpty.unary_!)
          matchEnd4({
            scala.Tuple2.apply[String, String](o7.get, o7.get);
            ()
          })
        else
          case6()
      };
```
SI-9006 Scaladoc: explicit companion and package links

The existing navigation mechanisms have proved hard to discover for newcomers
to Scaladoc.

This commit adds textual links in the navigation bar to the docs of the
companion (if defined) and to those of the enclosing package.
SI-9000  equals for immutable collections should check identity

`LinearSeqOptimized` now checks reference identity on `LinearSeq`s.

No unit test; this doesn't change visible behavior (save for side-effecting equals methods).
SI-8924 don't hold reference to list in iterator

Current implementation of LinearSeqLike.iterator holds
reference to complete sequence. This prevent garbage collecting
of List elements while we keep reference to iterator somewhere.

This commit removes reference from Iterator implementation. This
allow garbage collection of List while we iterating over its
elements (when there is no other references to List in our program).
Abstract over ClassPath and ClassRep

This commit is intended to create the possibility to plug in into
the compiler an alternative classpath representation which would be
possibly more efficient, use less memory etc. Such an implementation
- at least at the beginning - should exist next to the currently
existing one and be possible to turn on using a flag.

Several places in the compiler have a direct dependency on the
classpath implementation. Examples include backend's icode generator
and reader, SymbolLoaders, ClassfileParser. After closer inspection,
one realizes that all those places depend only on a very small subset
of classpath logic: they need to lookup classes from classpath. Hence
there's introduced ClassFileLookup trait that encapsulates that
functionality. The ClassPath extends that trait and an alternative
one also must do it.

There's also added ClassRepresentation - the base trait for ClassRep
(the inner class of ClassPath). Thanks to that the compiler uses
a type which is not directly related to the particular classpath
representation as it was doing until now.
Use new asClassPathString method and create FileUtils for classpath

The method asClasspathString is now deprecated. Moreover it's moved
to ClassFileLookup in the case someone was using it in some project
(an alternative classpath also will support it - just in the case).
All its usages existing in Scala sources are changed to
asClassPathString method. The only difference is the name.

Some operations on files or their names are moved from ClassPath to
the newly created FileUtils dedicated to classpath. It will be
possible to reuse them when implementing an alternative classpath
representation. Moreover such allocation-free extension methods like
the one added in this commit will improve the readability.
Define interface for flat classpath and add package loader using it

This commit introduces the base trait for flat classpath - an
alternative classpath representation. In accordance with the idea
and the experimental implementation of @gkossakowski, this
representation will try to make the best use of the specificity of
a given file type instead of using AbstractFile everywhere. It's
possible as .NET backend is no longer supported and we can focus on
Java-specific types of files.

FlatClassPath extends ClassFileLookup which provides the common
interface used also by existing ClassPath.

The new implementation is called flat because it's possible to query
the whole classpath using just single instance.
In the case of the old (recursive) representation there's the
structure of nested classpath objects, where each such an object can
return only entries from one level of hierarchy but it returns also
another classpath objects for nested levels included in it.

That's why there's added dedicated PackageLoaderUsingFlatClassPath in
SymbolLoaders - approaches are different so also the way of loading
packages has to be different. The new package loader is currently
unused.

There's added also PackageNameUtils which will provide common methods
used by classpath implementations for various file types.
Add the flat classpath type aggregating flat classpath instances

There's added AggregateFlatClassPath - an equivalent of
MergedClassPath from the old implementation. It is supposed to group
classpath instances handling different files being directories, zips
or jars.

Unlike in the case of the old (recursive) implementation, there won't
be a deep, nested hierarchy of classpath instances - just one root
(aggregate) and a flat structure of its children.

AggregateFlatClassPath ensures the distinction of classpath entries
and merges corresponding entries for class and source files into one
entry. This is required as SymbolLoaders class makes use of this kind
of ClassRepresentation.

There are also added unit tests which check whether
AggregateFlatClassPath obtains correct entries from classpath
instances specified in a constructor and whether it preserves the
ordering in the case of repeated entries. There's added a test type
of flat classpath using VirtualFiles so it's easy to check the real
behaviour.
Add flat classpath implementation for directories

There's added the flat classpath implementation for directories using
java.util.File directly. Since we work with a real directory - not
the AbstractFile - we don't need to iterate all entries of a file to
get inner entries of some package. We can just find an adequate
directory for a package.

There are added implementations for a class- and a sourcepath. Both
extend DirectoryFileLookup which provides common logic.
Add flat classpath implementation for zip and jar files

This commit adds an implementation of flat classpath which can handle
both jar and vanilla zip files. In fact there are two versions - for
a class- and a sourcepath. Both extend ZipArchiveFileLookup which
provides common logic.

They use FileZipArchive. @gkossakowski made a comparison of different
ways of handling zips and jars (e.g. using javac's ZipFileIndex). He
stated that general efficiency of FileZipArchive, taking into account
various parameters, is the best.

FileZipArchive is slightly changed. From now it allows to find the
entry for directory in all directory entries without iterating all
entries regardless of a type. Thanks to that we can simply find
a directory for a package - like in the case of DirectoryFileLookup.

There's also added possibility to cache classpath representation of
classpath elements from jar and zip files across compiler instances.
The cache is just a map AbstractFile -> FlatClassPath. It should
reduce the number of created classpath and file instances e.g. in the
case of many ScalaPresentationCompilers in Scala IDE.

To prevent the possibility to avoid a cache, caches are created as
a part of factories responsible for the creation of these types of
the flat classpath.
Add flat classpath implementation using ManifestResources

There's added the flat classpath type using ManifestResources,
closely related to the support for JSR-223 (Scripting for the Java
Platform). It uses classes listed in the manifest file placed in the
JAR. It's related to jar files so it's created using
ZipAndJarFlatClassPathFactory and is cached.

In general currently it's not possible to use it in Scala out of the
box (without using additional tools such as jarlister) as this
support is postponed. The old classpath has been properly prepared in
the PR created by @rjolly https://github.com/scala/scala/pull/2238
so the new one also got this feature.

ManifestResources is a ZipArchive without a real underlying file
placed on a disk and in addition implementing some methods declared
in AbstractFile as unsupported operations. Therefore the
implementation has to use the iterator. I wanted to have the similar
behaviour as in the case of directories and zip/jar files - be able
to get a directory entry for a package without iterating all entries.
This is achieved by iterating all entries only once and caching
packages.

This flat classpath type was the last needed one.