SI-6379 adds MethodSymbol.exception

Following Simon’s request, this commit introduces a dedicated API
that can be used to acquire the list of exceptions thrown by a method,
abstracting away from whether it’s a Java or a Scala artifact.
SI-8192 adds ClassSymbol.isPrimaryConstructor

Exposes a popular code pattern in macros as a dedicated reflection API.
This simple commit, however, ended up being not so simple, as it often
happens with our compiler.

When writing a test for the new API, I realized that our (pre-existing)
MethodSymbol.isPrimaryConstructor API returns nonsensical results for
implementation artifacts (trait mixin ctors, module class ctors).

What’s even more funny is that according to our reflection internals,
even Java classes have primary constructors. Well, that’s not surprising,
because `primaryConstructor` is just `decl(ctorName).alternatives.head`.
Good thing that package classes don’t have constructors or that would
elevate the situation to three fries short of a happy meal.

At the moment, I’m too scared to fiddle with internal#Symbol.primaryConstructor,
because that could easily break someone right before RC1, so I simply
documented the findings in SI-8193 and postponed the actual work, except
for one thing - isJavaDefined symbols no longer have primary constructors.
SI-6484 adds Universe.typeOf[T](x: T)

This is a nice addition to Universe.typeOf[T], quite frequently useful
for inspecting ad-hoc types.

As promised by https://github.com/scala/scala/pull/1741, which represented
my previous stab at adding this API, I ran into problems when trying to
introduce the API naively.

  def typeOf[T](implicit ttag: TypeTag[T]): Type
  def typeOf[T: TypeTag](x: T): Type

The first problem came from the fact that even though they don't look
ambiguous, under certain circumstances, the couple of typeOf overloads
can become ambiguous. Concretely, ambiguity happens when T <: TypeTag[T],
which makes the compiler uncapable to choose an overload to typecheck
`typeOf[T](<materialized>: TypeTag[T])`. Luckily, defining x as a by-name
parameter fixes the problem.

  def typeOf[T](implicit ttag: TypeTag[T]): Type
  def typeOf[T: TypeTag](x: => T): Type

The second problem manifested itself in reification of snippets that
contained calls to typeOf. Apparently, materialized tags get rolled back
by reify as products of macro expansion, becoming replaced with
`implicitly[TypeTag[T]]`. Afterwards, subsequent rollback of TypeTree's
strips the replacement of its type argument, producing bare `implicitly`.
Back then when typeOf wasn't overloaded, this abomination typechecked
and worked correctly, but now, due to some weird reason, it stopped.
I have worked around this by performing the rollback on a larger scale -
instead of hunting down materialized tags, this commit detects calls
to typeOf and removes their implicit argument lists altogether.
SI-8194 adds Universe.symbolOf[T]

A very frequent use for a result of typeOf is obtaining an underlying
type symbol. Another thing that comes up occasionally at stack overflow
is a request to add facilities for reification of symbols.

This naturally suggests that our reflection API would benefit from a method
called symbolOf that can take a term or type argument and return an underlying
symbol.

While an API to extract a term symbol from an expression needs some time
to be designed and then implemented robustly (we don’t have untyped macros
so we’ll have to account for various desugarings), meaning that we probably
won’t have time for that in 2.11, a type symbol extractor seems to be
a very low-hanging fruit.
adds showDeclaration(sym: Symbol): String

As per Paul’s request, this commit exposes Symbol.defString, although
in a different way to ensure consistency with our other prettyprinting
facilities provided in the reflection API.
splits Type.normalize into dealias and etaExpand

normalize is a highly overloaded name and it also conflates two distinct
operators, so how about we give our users self-explaning atomic tools instead.
adds Type.typeArgs

It’s very probable that this is the single most requested method in the
entire reflection API of Scala 2.10.
SI-8063 exposes much needed conveniences for Type

As per Jason’s request, Type now features such important convenience
methods as typeArgs, typeParams, paramss, resultType and finalResultType
without requiring to perform any casts.
adds Type.companionType

Introduces a dedicated facility to go from a type to a type of its companion.
Previously we had to do something really horrible for that, something like:
tp.typeSymbol.companionSymbol.typeSignature.
sane semantics for Symbols.companionSymbol

While playing with tests for Type.companionType, I figured out that
companionSymbol isn’t what it seems to be:

scala> ScalaPackage.companionSymbol
res5: $r.intp.global.Symbol = <none>

scala> ScalaPackageClass.companionSymbol
res6: $r.intp.global.Symbol = package scala

Or even funnier observation:

scala> class C; object C
defined class C
defined object C

scala> val classC = typeOf[C].typeSymbol
classC: $r.intp.global.Symbol = class C

scala> val moduleC = classC.companionSymbol
moduleC: $r.intp.global.Symbol = object C

scala> classC.companionSymbol == moduleC
res0: Boolean = true

scala> moduleC.companionSymbol == classC
res1: Boolean = true

scala> moduleC.moduleClass.companionSymbol == moduleC
res2: Boolean = true

Of course, I rushed to clean this up, so that `companionSymbol` only
returns something other than NoSymbol if the target has a companion in
the common sense, not wrt the internal “class with the same name in the
same package” convention of scalac, and that `companionSymbol` for
module classes is a class, not a source module.

Unfortunately it’s not that easy, because api.Symbol#companionSymbol
has the same name as internal.Symbol#companionSymbol, so we can’t change
the behavior of the former without changing the behavior of the latter.

Therefore I deprecated api.Symbol#companionSymbol and introduced a replacement
called api.Symbol#companion with sane semantics.
ValOrDefDef.name is now TermName

Back then when we planned to introduce type macros, we relaxed the type
of DefDef.name from TermName to Name in order to potentially be able to
accommodate type names for type macros.

Since then, type macros have been cancelled (and, for the record, my
implementation of type macros in paradise 1.0 didn’t involve DefDefs
with TypeNames), and we’ve rolled back the change to DefDef.name.

What we forgot to do, however, was to change the type of ValOrDefDef.name,
which is taken care of in this commit.
SI-8118 simplifies Annotation down to a plain Tree

As per https://groups.google.com/forum/#!topic/scala-internals/8v2UL-LR9yY,
annotations don’t have to be represented as AnnotationInfos and can be
reduced to plain Trees.

Due to compatibility reasons and because of the limitations of the cake
pattern used in implementing current version of Reflection, we can’t
just say `type Annotation = Tree`, however what we can definitely do is
to deprecate all the methods on Annotation and expose `tree: Tree` instead.
SI-6814 adds typechecker modes to c.typecheck

As per multiple user requests, this commit introduces a shortcut
to typecheck trees under multiple different modes: terms (EXPRmode,
was exposed in Scala 2.10) and types (TYPEmode).

Looking into the rest of a dozen of internal typechecker modes, to the
best of my knowledge, I can’t find other modes that we could expose.
FUNmode is useful, but very situational. PATTERNmode is useful, but
also situational, because we don’t expand macros inside patterns
except for whitebox extractor macros. The rest (e.g. POLYmode or TAPPmode)
are too low-level.
SI-6931 cleans up the position API

I have finally overcome my fear of positions and got to cleaning up its
public interface.

Apparently it isn’t so bad, since there’s a sane core of methods (thanks
to whoever wrote the comments to internal#Position):
  1) Checks to distinguish offsets, opaque ranges and transparent ranges
  2) Essentials that inclide start, point, end and source
  3) Factories that create new positions based on existing ones

It looks like methods from the 3rd group are exactly what we’ve been looking
for in SI-6931, so we have nothing to add in this commit.
SI-8086 addresses problem with calling Symbol.getter

Due to an unintended clash between `def getter: Symbol` (public reflection)
and `def getter(base: Symbol): Symbol` (internal reflection), the former
is uncallable from compiler internals and/or REPL’s power mode.

While both methods are guarded by compatibility constraints, we can’t
solve this problem radically and will have to live with it for some time
Thankfully, a replacement for `sym.getter` is quite approachable, namely:
`sym.getter(sym.owner)`.

In the meanwhile, I’ve deprecated the internal `getter` method by
renaming it to `getterIn`, also touching a nearby `superSymbol`. In the next
release we’ll be able to fix the name clash for good.
SI-6441 removes Symbol.isOverride

`Symbol.isOverride` joins `Symbol.isLocal` in the unfortunate family
of methods for which we had to break source compatibility because of
their utter brokenness.

Apparently, `isOverride` only returns true for those symbols that have
the OVERRIDE flag set (i.e. the ones that are derived from source definitions
that have the `override` modifier specified next to them). Of course,
this is very confusing, and that’s exacerbated by the fact that we can’t
fix this behavior, because there’s `internal#Symbol.isOverride` that someone
might rely on.

Given that there’s perfectly working `Symbol.allOverriddenSymbols`,
this commit removes the `Symbol.isOverride` API altogether.
SI-8188 NPE during deserialization of TrieMap

The writer was using the constructor headf and ef instead of the internal vars hashingobj and equalityobj.
Merge pull request #3526 from retronym/ticket/1786-cycle

SI-8276 Test for cyclic error caused by (reverted) SI-1786 fix
Merge pull request #3376 from Ichoran/issue/8153

SI-8153 Mutation is hard, let's go shopping with an empty list
SI-8177 tidy up in type reification