SI-2066 Plug a soundness hole higher order type params, overriding

PolyType-s parameterized by higher order type parameters (HOTPs)
should only be relatable with <:< or =:= if the variances of their
type parameters line up. This is only enforced for HOTPs defined in
method type arguments.

Invariant type parameters subsume variant ones. Concretely, as
described by @S11001001:

> A method taking [F[_]] can implement a method taking [F[+_]].
> Likewise, a method taking [F[_[+_]]] can implement a method
> taking [F[_[_]]], as with [F[_[_[_]]]] implementing [F[_[_[+_]]]],
> and so on, the variance subsumption flipping at each step.
>
> This is just the opposite of the variance for passing type
> parameters to either instantiate types or call methods; a F[+_]
> is a suitable F[_]-argument, a F[_[_]] a suitable F[_[+_]]-argument,
> and so on.
>
> All of the above rules can be duplicated for contravariant positions
> by substituting - for +. Also, something similar happens for
> weakening/strengthening bounds, I believe.

These cases are tested in the `// okay` lines in `neg/t2066.scala`.
SI-8046 Fix baseTypeSeq in presence of type aliases
Pending test for SI-6161

Not solved with base type dealiasing
SI-8046 Only use fast TypeRef#baseTypeSeq with concrete base types

We can only compute the base type sequence (BTS) of a `TypeRef` by
element-wise transforming the BTS of the referenced symbol if
there are no abstract types in its BTS type symbols.

In the now-working test case, `pos/t8046.scala`, the difference
between the old and new calculation of the BTS is:

    this                 = Three.this.Alias[Int]
    sym.info.baseTypeSeq = BTS(One.this.Op[A],Any)
    mapped BTS           = BTS(Three.this.Op[Int],Any)
    full BTS             = BTS(Three.this.Op[Int],Int => Int,Object,Any)

The change to account for PolyType in ArgsTypeRef#transform is now
needed to avoid the full BTS of:

    BTS(Three.this.Op[A],A => A,Object,Any)

Interestingly, everything actually works without that change.
SI-7897, SI-6675 improves name-based patmat

This emerges from a recent attempt to eliminate pattern matcher
related duplication and to bake the scalac-independent logic
out of it. I had in mind something a lot cleaner, but it was
a whole lot of work to get it here and I can take it no further.

Key file to admire is PatternExpander.scala, which should
provide a basis for some separation of concerns.

The bugs addressed are a CCE involving Tuple1 and an imprecise
warning regarding multiple pattern crushing.

Editorial: auto-tupling unapply results was a terrible idea which
should never have escaped from the crib. It is tantamount to
purposely throwing type safety down the toilet in the very place
where people need type safety the most. See SI-6111 and SI-6675 for
some other comments.
SI-7850 CCE in patmat with invalid isEmpty.

Name-based pattern matcher needed some hardening against
unapply methods with the right name but wrong types. Only
isEmpty methods which return Boolean are acceptable.
Catching it directly rather than indirectly also allowed
for better error messages.
SI-8045 type inference of extracted value

Test case for SI-8045, fixed by the preceding commits.
Eliminated some dead/redundant code based on review.
Finalized some case classes, for better static checking.
SI-6615 PagedSeq's slice throws a NPE if it starts on a page that hasn't been computed yet

Made sure to addMore when roving forward on a slice into unpaged territory.
SI-8058 Better support for enum trees

Replace the approach of “detect some magic combination of flags to
trigger some action” by introducing an enum flag which makes the
semantics and the intentions of the code using it more explicit.

This basically involves wiring up the existing ACC_ENUM bit to a new
modifier flag and making sure it is set correctly when encountering
enums.

The existing enum tests files/pos/t5165 and files/pos/t2764 keep
working, showing that this hasn't introduced any obvious regressions.

Tests for the changes in Namer which prevent scalac from messing with
enum trees can't be added yet, because one currently can't define an
enum in Scala without the help of the macro paradise.
The intention is to add the @enum macro as a full test suite as soon
as one can depend on macro annotations.

One might wonder why we don't check for
    clazz.superClass == JavaEnumClass (where clazz is the owning class)
in isEnumConstant.

The reason is that this causes illegal cyclic reference error.

Explanation by Eugene why this happens:

(23:17:52) xeno_by: so here's what happens as far as I can understand at 11pm :)
(23:18:09) xeno_by: scalac tries to complete the signature of the newly expanded class
(23:18:11) xeno_by: to do that
(23:18:40) xeno_by: to do that it needs three things
(23:18:51) xeno_by: because the signature of a class is ClassInfoType which consists of three things
(23:19:05) xeno_by: parents
(23:19:08) xeno_by: decls
(23:19:09) xeno_by: and symbol
(23:19:20) xeno_by: symbol is easy - it's already there
(23:19:30) xeno_by: parents are also easy
(23:19:39) xeno_by: you just typecheck the things that come after "extends"
(23:19:42) xeno_by: but decls are tricky
(23:19:51) xeno_by: scalac goes through all the members of the class
(23:20:03) xeno_by: and doesn't typecheck them... no, it doesn't
(23:20:07) xeno_by: it just enters them
(23:20:32) xeno_by: i.e. creates symbols for them and assigns lazy completers to those symbols so that if someone wants to know their signatures, they will go through the completers
(23:20:34) xeno_by: and then
(23:20:38) xeno_by: wait
(23:20:40) xeno_by: there's one but
(23:20:42) xeno_by: BUT
(23:20:47) xeno_by: while we enter those symbols
(23:20:53) xeno_by: our ClassInfoType is not ready yet
(23:21:09) xeno_by: the class we're completing is still considered to be in the middle of being completing
(23:21:12) xeno_by: so
(23:21:24) xeno_by: when inside enterSym you try to ask that class for its super class
(23:21:35) xeno_by: what happens is that check asks the class for its type signature
(23:21:45) xeno_by: the ClassInfoType that consists of parents and decls
(23:21:54) xeno_by: even though the parents are already calculated
(23:22:01) xeno_by: the ClassInfoType as a whole is not
(23:22:16) xeno_by: so scalac says that you're trying to complete something that's currently being completed
(23:22:20) xeno_by: cyclic reference error
(23:22:59) xeno_by: "cyclic" in English looks an awful lot like "суслик" in Russian (which means "gopher")
SI-4841 CLI help update for -Xplugin

The argument to `-Xplugin` is now a comma-separated list of paths.
This commit updates the option descriptor and a code comment.
SI-8128 Fix regression in extractors returning existentials

The advent of the named based pattern matcher brought with it
a change in the way we determine the type of the value in the
"match monad". We used to take the base type to `Option` or `Seq`
(guided by the method name in `unapply` vs `unapplySeq`), and
simply use the type argument.

Name-based patmat, instead, uses the result type of methods in the
type. For example, the element type of an Option-like extractor
result is given by the result type of the no-args `get` method.

This approach, however, swiftly runs aground when navigating the
existential atolls. Here's why:

    scala> class F[_]
    defined class F

    scala> val tp = typeOf[Some[F[X]] forSome { type X }]
    warning: there were 1 feature warning(s); re-run with -feature for details
    tp: $r.intp.global.Type = scala.this.Some[F[X]] forSome { type X }

    scala> tp.baseType(typeOf[Option[_]].typeSymbol).typeArgs.head
    res10: $r.intp.global.Type = F[X] forSome { type X }

    scala> tp.memberType(tp.member(nme.get)).finalResultType
    res11: $r.intp.global.Type = F[X]

`res10` corresponds to 2.10.x approach in `matchMonadResult`.
`res11` corresponds to the new approach in `resultOfMatchingMethod`.

The last result is not wrapped by the existential type. This results
in errors like (shown under -Ydebug to turn un accurate printing of
skolems):

    error: error during expansion of this match (this is a scalac bug).
    The underlying error was: type mismatch;
     found   : _$1&0 where type _$1&0
     required: _$1
      (0: Any) match {
               ^
    one error found

This commit addresses the regression in 2.10.x compatible extractors
by using the 2.10 approach for them.

The residual problem is shown in the enclosed pending test.
Merge pull request #13 from retronym/ticket/8128

SI-8128 Fix regression in extractors returning existentials
Fix infinite recursion in name-based patmat.

I discovered on erroneous code it could fall into a loop looking
for product selectors, because ErrorType always claims to have
whatever member you're asking about.
*boxContext => *box.Context	, *boxMacro => *box.Macro

Performs the following renamings:
* scala.reflect.macros.BlackboxContext to scala.reflect.macros.blackbox.Context
* scala.reflect.macros.BlackboxMacro to scala.reflect.macros.blackbox.Macro
* scala.reflect.macros.WhiteboxContext to scala.reflect.macros.whitebox.Context
* scala.reflect.macros.WhiteboxMacro to scala.reflect.macros.whitebox.Macro

https://groups.google.com/forum/#!topic/scala-internals/MX40-dM28rk
changes bundles to be classes, not traits extending Macro

Adjusts bundle notation to read `class Bundle(val c: Context)` instead of
`class Bundle extends Macro`. This avoids calling compileLate in the
macro compiler and associated tooling problems.
prohibits constructor overloading for macro bundles

As per Jason’s feedback, this commit handles overloaded constructors
in macro bundles. The backend now checks that we have a constructor of
a correct type. The frontend now prohibits multiple constructors altogether.
removes Scala reflection-based macro runtime

This code is currently unused, so I’m removing it in order to avoid bitrot.
Once we’re sure that we can trust Scala reflection with our macros, the
removed file can be easily reinstated.
Merge pull request #3303 from Ichoran/issue/6615

Fixes SI-6615, NPE on slice of PagedSeq.