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
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.
SI-8474  Inconsistent behavior of patch method

Changed Iterator to be consistent with other collections.

Also fixed SeqViewLike to validate/constrain inputs.

No specific tests; quasi-comprehensive collection tests will cover this later.
SI-5254 running an empty scala script should succeed

The script runner made the assumption that "compilation succeeded"
implies "there is a Main class to run", but this can be wrong if the
script is empty (or only contains imports/comments).

The ScriptRunner now uses the ClassPath utility to check if there really
is a main class. If not, it doesn't try to run it and returns
peacefully. This also makes `scala -e ''` succeed.
[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-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

```
SI-8410 Summarize if warnings and not disabled

Simplify the conditional and emit the summary if
there were buffered warnings and the user didn't
explicitly disable this setting.

The working assumption is that using fatal-warnings
to turn on summaries was either an outdated heuristic
or just due to a faulty merge. Or wait, was it for
-feature, which is not enabled when warnings are
issued against it?
Fix assertThrows, and the behaviors that it shadowed

The test in StdNamesTest was introduced in cff8b569, where newTermName
would throw on a negative length. In b090f97 this was changed to fix
the negative length, but the test was not adapted (as it didn't fail).
Merge pull request #3937 from som-snytt/issue/8787-doc-backport

[backport] SI-8787 Backport Regex doc
-Ystatistics accepts a list of phases, cleanups in MultiChoiceSetting

MultiChoiceSetting and Xlint with its deprecated aliases is now a bit
simpler, but there's still room for improvement, as noted in comments.
Merge commit 'b5759ef' into merge/2.10-to-2.11-sept-2
Merge branch '2.10.x' into merge/2.10-to-2.11-sept-2