SI-8589 Performance improvement for ArrayCharSequence.toString
[backport] transformers no longer ignore UnApply.fun

Backports 7122560063 and 4133eb8454 from the 2.11.x branch
Merge pull request #3752 from jeroentervoorde/SI_8589

SI-8589 Performance improvement for ArrayCharSequence.toString
Prevent SI-8314 by adding a test

The original issue was fixed already. This test is just for make sure.
Merge pull request #3904 from kzys/jira-8314-2.10.x

Prevent SI-8314 by adding a test
[backport] SI-7710 fix memory performance of RegexParsers in jdk7u6+

Backport of scala/scala-parser-combinators@91584dc.

---

Starting with 1.7.0_06 [1], String.substring no longer reuses the internal
char array of the String but make a copy instead. Since we call
subSequence twice for *every* input character, this results in horrible
parse performance and GC.

With the benchmark from the (duplicate) ticket SI-8542, I get:

BEFORE:
    parseAll(new StringReader(String))
    For 100 items: 49 ms
    For 500 items: 97 ms
    For 1000 items: 155 ms
    For 5000 items: 113 ms
    For 10000 items: 188 ms
    For 50000 items: 1437 ms
    ===
    parseAll(String)
    For 100 items: 4 ms
    For 500 items: 67 ms
    For 1000 items: 372 ms
    For 5000 items: 5693 ms
    For 10000 items: 23126 ms
    For 50000 items: 657665 ms

AFTER:
    parseAll(new StringReader(String))
    For 100 items: 43 ms
    For 500 items: 118 ms
    For 1000 items: 217 ms
    For 5000 items: 192 ms
    For 10000 items: 196 ms
    For 50000 items: 1424 ms
    ===
    parseAll(String)
    For 100 items: 2 ms
    For 500 items: 8 ms
    For 1000 items: 16 ms
    For 5000 items: 79 ms
    For 10000 items: 161 ms
    For 50000 items: 636 ms

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6924259
Merge pull request #3860 from gourlaysama/wip/t7710-backport

[backport] SI-7710 fix memory performance of RegexParsers in jdk7u6+
Merge pull request #3865 from xeno-by/topic/extractor-macros-210x

[backport] transformers no longer ignore UnApply.fun
Set currentUnit while generating bytecode.
Remove Tracked, add type information to ClassBType

Before this change, a ClassBType was just a name. The `exemplars` map
stored a Tracked instance for every ClassBType. Tracked stored
type information that is required later in the backend when things
may run concurrently. In particular: superclass, interfaces, flags
and information for emitting the InnerClass attribute. Now we put all
the information stored in Tracked directly in the ClassBType.

There is still one hash map: `classBTypeFromInternalNameMap` maps
a JVM internal class name (e.g. "scala/Predef$") to the corresponding
ClassBType. This map is used during bytecode generation, when the
ASM framework computes stack map frames.

In order to compute stack map frames, the ASM framework needs to be
able to get the LUB of two types. The default implementation uses
reflection to get type information, however that doesn't work in our
case: the classes we compile are not on the classpath. So instead,
the backend overwrites the method `getCommonSuperClass` of the
ClassWriter. This method receives two class internal names and
computes their LUB. This is done by looking up the ClassBTypes in the
`classBTypeFromInternalNameMap` and invoking `jvmWiseLUB`.

This commit was reviwed in https://github.com/scala/scala/pull/3855.
It consists of all commits labelled [squash-after-review], squashed
into one.
Add the ACC_DEPRECATED flag in javaFlags, instead of each call site.
Minor cleanups, integrating review feedback

Review was in https://github.com/scala/scala/pull/3855
Integrate CoreBTypes by composition (not inheritance), non-var fields

Make the fields of CoreBTypes non-variable. Instead, replace the
CoreBTypes instance on each compiler run. That results in fewer
variables, and the initialization code is directly where the fields
are declared, instead of an init method.
Fix indentation in delambdafy
SI-8803 generate super accessor for super[A], if A is outer superclass

    class C extends A with T {
      class I {
        C.super[T]
        C.super[A]
      }
    }

A super call in a nested class of the form super[T] where T is a
parent trait of the outer class doesn't need an accessor: mixin can
directly re-route the call to the correct implementation class - it's
statically known to be T$class.

However, if a nested class accesses super[A] and A is the superclass
of the outer class (not a trait), then we need a super accessor in the
outer class.

We need to add the mixin name to the super accessor name, otherwise
it clashes with non-qualified super accessors.
SI-8498 @compileTimeOnly should be aware of bridge methods.

Calling a @compileTimeOnly method from another @compileTimeOnly
method happens when the former gets a bridge method. It should not
throw an error. Calling the bridge or the method will anyway.
[backport] SI-8787 Backport Regex doc

Backport the doc with two material changes:

1. need to use Groups to extract from Match,
so say that in lieu of the 2.11 advice that
the Regex instance can be used without
recomputing the match;

2. and relatedly, in 2.10 there is no secondary
constructor, so the doc for group names is
moved back up to the class doc.

Original doc update on PR #3923 was:

0e26910372d349c6ff7bbaa17fc8fe0bf568c5fe

f98c53cb03f800b3d790f3866ab90f827fd131f5
SI-8823 Exclude specialized methods from extension method rewrite

If a value class extends a specialized class, it can sprout
specialized members after the specialization info transformer has run.
However, we only install extension methods for class members we know
about at the extmethods phase.

This commit simply disables rewiring calls to these methods in
erasure to an extention method. This follows the approach taken
from super accessors.

Note: value class type parameters themselves currently are not
allowed to be specialized.
SI-8828 fix regression in Xlint visibility warning for sealed classes

5dfcf5e reverted a change to `Symbol#isEffectivelyFinal` (made in
adeffda) that broke overriding checks, and moved the new enhanced
version to a new method.

However, the test for inaccessible type access still uses the old one,
so it lost the ability to see that the owner of some method is either
final or sealed and not overridden.

This just makes it use the new `isEffectivelyFinalOrNotOverriden`.
SI-8410 Don't warn fatally on disabled flag

Since boolean settings can now be set false by user,
summary warnings should not be issued when the flag
is explicitly off (as opposed to unset, default).

In particular, `-Xfatal-warnings` should not fail
if there were no warnings otherwise.

```
$ ~/scala-2.11.2/bin/scalac -d /tmp -deprecation:false test/files/pos/t8410.scala
$ ~/scala-2.11.2/bin/scalac -d /tmp -deprecation:false -Xfatal-warnings test/files/pos/t8410.scala
warning: there were three deprecation warnings; re-run with -deprecation for details
error: No warnings can be incurred under -Xfatal-warnings.
one warning found
one error found

```
After this commit:
```
$ skalac -d /tmp -Xfatal-warnings test/files/pos/t8410.scala
warning: there were three deprecation warnings; re-run with -deprecation for details
error: No warnings can be incurred under -Xfatal-warnings.
one warning found
one error found
$ skalac -d /tmp -deprecation:false -Xfatal-warnings test/files/pos/t8410.scala
```
Similarly for other collecting flags:
```
$ skalac -d /tmp -optimise -Yinline-warnings -deprecation:false -Xfatal-warnings test/files/pos/t8410.scala
test/files/pos/t8410.scala:14: warning: Could not inline required method dropWhile because access level required by callee not matched by caller.
  def k = List(0).dropWhile(_ < 1)   // inlining warns doubly
                           ^
test/files/pos/t8410.scala:14: warning: At the end of the day, could not inline @inline-marked method dropWhile
  def k = List(0).dropWhile(_ < 1)   // inlining warns doubly
                           ^
error: No warnings can be incurred under -Xfatal-warnings.
two warnings found
one error found
$ skalac -d /tmp -optimise -Yinline-warnings:false -deprecation:false -Xfatal-warnings test/files/pos/t8410.scala

```
Footnote: handling of deprecated locals also changed in 2014:
```
$ ~/scala-2.11.0-M7/bin/scalac -d /tmp -deprecation -Xfatal-warnings test/files/pos/t8410.scala
test/files/pos/t8410.scala:8: warning: method f in object Test is deprecated:
  Console println f  // warns
                  ^
error: No warnings can be incurred under -Xfatal-warnings.
one warning found
one error found
$ ~/scala-2.11.0-M8/bin/scalac -d /tmp -deprecation -Xfatal-warnings test/files/pos/t8410.scala
test/files/pos/t8410.scala:5: warning: method _f is deprecated:
  def g = { @deprecated("","") def _f = f ; _f }                   // warns in 2.11.0-M8
                                            ^
test/files/pos/t8410.scala:6: warning: class X is deprecated:
  def x = { @deprecated("","") class X { def x = f } ; new X().x } // warns in 2.11.0-M8
                                                           ^
test/files/pos/t8410.scala:8: warning: method f in object Test is deprecated:
  Console println f  // warns
                  ^
error: No warnings can be incurred under -Xfatal-warnings.
three warnings found
one error found

```