SI-8052 Disallow `macro` as an identifier

Note that the change could look a lot cleaner, at the cost of returning
more generic error messages. I decided that at least for 2.11 I'll keep
scalac remembering that macro was a standard identifier name once, so
that we can point out more precisely what's wrong with users' code.
typeCheck => typecheck

This method has always been slightly bothering me, so I was really glad
when Denys asked me to rename it. Let’s see how it pans out.
refactors macroExpandApply

Moves some code around to clearly define the concepts that the method
operates on: 1) `innerPt`, which is expected type provided by the macro
def return type, 2) `outerPt`, which is expected type provided by the
enclosing context.

Once everything is clearly defined, the gist of the expander fits in
a few lines in its end. If blackbox, do this. If whitebox, do that.

Note that unlike the subsequent commit, this commit doesn’t change
the way how macro expansion works. It just clears everything out, so that
the upcoming changes can be applied in a concise and comprehensible manner.
whitebox macros are now first typechecked against outerPt

Even though whitebox macros are supposed to be used to produce expansions
that refine advertised return types of their macro definitions, sometimes
those more precise types aren’t picked up by the typechecker.

It all started with Travis generating structural types with macros
and noticing that typer needs an extra nudge in order to make generated
members accessible to the outside world. I didn’t understand the mechanism
of the phenomenon back then, and after some time I just gave up.

Afterwards, when this issue had been brought up again in a different
StackOverflow question, we discussed it at reflection meeting, figured out
that typedBlock provides some special treatment to anonymous classes,
and it became clear that the first macro typecheck (the one that types
the expansion against the return type of the corresponding macro def)
is at fault here.

The thing is that if we have a block that stands for a desugard anonymous
class instantiation, and we typecheck it with expected type different from
WildcardType, then typer isn’t going to include decls of the anonymous class
in the resulting structural type: https://github.com/scala/scala/blob/master/src/compiler/scala/tools/nsc/typechecker/Typers.scala#L2350.
I tried to figure it out at https://groups.google.com/forum/#!topic/scala-internals/eXQt-BPm4i8,
but couldn’t dispel the mystery, so again I just gave up.

But today I had a profound WAT experience that finally tipped the scales.
It turns out that if we typecheck an if, providing a suitable pt, then
the resulting type of an if is going to be that pt, even though the lub
of the branch types might be more precise. I’m sure that reasons for this
behavior are also beyond my understanding, so I decided to sidestep this problem.

upd. Here’s Jason’s clarification: Doing thing differently would require
us to believe that "'Tis better to have lubbed and lost than never to have
lubbed at all." But the desire for efficiency trumps such sentimentality.

Now expansions of whitebox macros are first typechecked against outerPt,
the expected type that comes from the enclosing context, before being
typechecked against innerPt, the expected type that comes from the return
type of the macro def. This means that now outerPt provides the correct
expected type for the initial, most important typecheck, which makes
types more precise.
drops the redundant typecheck of blackbox expansions

While fixing the problem with the order of typechecks for whitebox expansions,
I realized that we’re doing redundant work when expanding blackbox macros.
Concretely, typechecking blackbox expansions looked as follows:

  val expanded1 = atPos(enclosingMacroPosition.focus)(Typed(expanded0, TypeTree(innerPt)))
  val expanded2 = typecheck("blackbox typecheck #1", expanded1, innerPt)
  typecheck("blackbox typecheck #2", expanded1, outerPt)

Or, if we reformulate it using quasiquotes (temporarily not taking
positions into account, since they aren’t important here):

  val expanded2 = typed(q”$expanded: $innerPt”, innerPt)
  typed(expanded2, outerPt)

In this formulation, it becomes apparent that the first typecheck is
redundant. If something is ascribed with some type, then typechecking
the ascription against that type does nothing useful.

This is also highlights one of the reasons why it would be really nice
to have quasiquotes used in the compiler. With them, it’s easy to notice
things that would otherwise remain buried behind swaths of boilerplate.
SI-7971 Handle static field initializers correctly

Before this fix, static fields where erroneously treated like instance
fields and the initialization was moved into the constructor.

With this fix, the static initializer statements go into the static
initializer of the class (called “<STATIC> def init” in Scala,
<clinit> in Java). The statements are added to an existing
static initializer method or, if no such method exists, a new static
initializer method is created and added to the class.
Improvements to partest-ack, plus partest-paths.

I noticed partest-ack was not finding all matching tests, and
fixed that. Also cleaned up the ack options so they're understood
by the latest version of ack.

Along the way I broke the canonicalization functionality out into its
own script so it can easily be used from other places.
SI-8017 Value class awareness for -Ydelamdafy:method

The delambdafy creates a bridge method which requires adaptation
of the result type to the generic `Object`, which is the erased
return type of FunctionN.

This bridge building reused some code from erasure, now refactored
into TypeAdaptingTransformer.

But, it was running into problems with:

    class C(a: Int) extends AnyVal
    (x: Any) => new C(0)

It created (forgive the pseudo quasiquote syntax):

    class anonfun$ extends Function1[Any, C] {
       def apply#1(a: Object): Int = 0
       <bridge> def apply#2(a: Object): Object = {
         val result: Int = apply#1(a)
         ${adapt(Ident("result"), ObjectType)}
       }
    }

This resulted in primitive boxing, rather than value class boxing.

Instead, we need the call to the main apply method to be typed
as `ErasedValueClass(C, Int)`, which `adapt` takes as a trigger
to perform value class boxing.

Finally, we have to run the post-erasure transformer over the adapted
tree to eliminate remnants of `ErasedValueClass` from the types of
trees.
Merge pull request #3273 from paulp/pr/ack

Improvements to partest-ack, plus partest-paths.
SI-8047 change fresh name encoding to avoid owner corruption

Previously a following encoding was used to represent fresh
names that should be created at runtime of the quasiquote:

  build.withFreshTermName(prefix1) { name$1 =>
    ...
      build.withFreshTermName(prefixN) { name$N =>
        tree
      }
    ...
  }

It turned out that this encoding causes symbol corruption when
tree defines symbols of its own. After being spliced into anonymous
functions, the owner chain of those symbols will become corrupted.

Now a simpler and probably better performing alternative is
used instead:

  {
    val name$1 = universe.build.freshTermName(prefix1)
    ...
    val name$N = universe.build.freshTermName(prefixN)
    tree
  }

Here owner stays the same and doesn’t need any adjustment.
Use t- prefix instead of si- prefix for test files
SI-6120 Suppress extra warnings

This is a mere polish for the fix to allow multiple warnings.

Sensibility checks in refchecks were shown to be redundant.

This commit includes a mild refactor to reduce tabbage, and
uses a local var to flag that a warning has already been emitted.

It would be better to have the checks return true if warned,
to facilitate `nonSensically || unrelatedly`, etc., but that's
a lot of `else false`.

The check files that were updated with the redundant warnings
are reverted.
Merge pull request #3236 from xeno-by/topic/wildbox-macros

(2.11.0-M8) whitebox macros are now first typechecked against outerPt
duplicates macro arguments before expansion

As discussed with Jason, this is an important dimension of defenses that
we can build to ensure robustness of the macro engine.

This commit is important in the context of the upcoming patch to the
presentation compiler that will throw away expansions and keep original
macro applications (only when run in presentation compiler mode) so that
hyperlinking in macro arguments starts working in the IDE.

Duplication of macro arguments will make sure that macro arguments, which
are going to become exposed to the IDE, can’t become corrupted by possibly
misbehaving or misguided macros.
Merge pull request #3224 from soc/SI-7971

SI-7971 Handle static field initializers correctly
makes boxity of fast track macros configurable

Previously, all built-in macros were assumed to be whitebox, but that’s
actually not the case. Just quasiquote macros have to be whitebox, while
the rest can be blackbox.

This also fixes SI-8091, because blackbox macros are typechecked differently
and therefore the necessary implicit conversion kicks in. If `f”...”` were
to remain a whitebox macro, then due to the changes introduced in commit
https://github.com/scala/scala/commit/a3b33419b02cafb7e2c6fed6dd96151859fc7d77
we would have to explicitly ascribe its expansion as String to achieve the same effect.

After I made reify blackbox, several tests had to be changed, because
we now explicitly ascribe the expansion with `c.Expr[T]`, which changes `toString`.
Also, a number of less obvious corrections had to be applied, because
things like `reify(<constant>).splice` have stopped being optimized away
due to `reify(<constant>)` no longer having a narrow `c.Expr[<constant>.type]`,
making it ineligible for constant folding.

Moreover, this change forced me to adjust our approach to positioning
blackbox wrappings, because after being changed to blacbox and starting using
wrappings, f”...” interpolators used in the compiler started crashing
-Yrangepos builds. Now wrapping Typed nodes are assigned with transparent
positions.
SI-5508 Fix crasher with private[this] in nested traits

Currently, accessors for private local trait fields are added
very late in the game when the `Mixin` tree transformer treats the
trait. By contrast, fields with weaker access have accessors created
eagerly in `Namers`.

    // Mixin#addLateInterfaceMembers
    val getter = member.getter(clazz)
    if (getter == NoSymbol) addMember(clazz, newGetter(member))

`addMember` mutates the type of the interface to add the getter.
(This seems like a pretty poor design: usually if a phase changes
types, it should do in an `InfoTransformer`.)

However, if an inner class or anonymous function of the trait
has been flattened to a spot where it precedes the trait in the
enclosing packages info, this code hasn't had a chance to run,
and the lookup of the getter crashes as mixins `postTransform`
runs over a selection of the not-yet-materialized getter.

    // Mixin#postTransform
	case Select(qual, name) if sym.owner.isImplClass && !isStaticOnly(sym) =>
	  val iface  = toInterface(sym.owner.tpe).typeSymbol
	  val ifaceGetter = sym getter iface

This commit ensures that `Flatten` lifts inner classes to
a position *after* the enclosing class in the stats of the
enclosing package.

Bonus fix: SI-7012 (the followup ticket to SI-6231 / SI-2897)
Remove obsolete diagnostic error for SI-6231

The previous commit means we no longer have a test that
gets to this point.
Merge pull request #3257 from xeno-by/topic/duplicate-macro-args

(2.11.0-M8) duplicates macro arguments before expansion
Merge pull request #3234 from retronym/ticket/5508-3

 Fix crasher with private[this] in nested traits