SI-7883 - don't iterate over all keys in MapWrapper.containsKey()
SI-7883: Added a comment per CR feedback from @adriaanm, @Ichoran
SI-3871 Missing test case for protected bug.

c39f26382dddaa7 fixed the bug but didn't commit a test case.
IterableLike grouped : fix documentation


scala> Seq(1,2,3).grouped(2).toList
res1: List[Seq[Int]] = List(List(1, 2), List(3))
IterableLike.grouped() : More explicit documentation
Filter JVM debug output for custom options in partest

The Picked up _JAVA_OPTIONS line occurs on Sun's JDK as a debug output when you use that variable to set up custom VM options
deprecates raw tree manipulation facilities in macros.Context
changes some manual tree constructions in macro tests to quasiquotes
SI-6026 REPL checks for javap before tools.jar

If javap is already available, don't go hunting for tools.jar

This avoids the getResource bug in AbstractFileClassLoader.
[nomaster] SI-6026 backport getResource bug fix

Submitted to master under SI-4936, this fix allows :javap
to work when tools.jar is discovered by REPL.
fixes handling of fancy nested classes in runtime reflection

Replaces the `jclazz.isMemberClass` check for whether we have an
inner/nested class with `jclazz.getEnclosingClass != null`, because there
exist classes produced by javac (see the attached jar file and the test log)
which have the following properties:
  * They are nested within a parent class
  * getEnclosingClass returns a non-null value
  * isMemberClass returns false

Previously such classes were incorrectly treated as non-nested, were
incorrectly put into an enclosing package rather than an enclosing class,
and had their names trimmed in the process, leading to situations when
a package has multiple declarations with the same name. This is now fixed.

When changing the check, we need to be careful with interpretation of
what Class.getEnclosingXXX methods return. If getEnclosingClass produces
a non-null result, this doesn't mean that the class is inner or nested,
because getEnclosingClass is also not null for local classes (the ones
with getEnclosingMethod != null || getEnclosingConstructor != null).
This is expressed in the order of pattern match clauses in `sOwner`.

Now when the bug is fixed, I also revert b18a2f8798b2, restoring a very
important integrity check in runtime reflection, which I had to disable
a couple hours ago to fix a master breakage. More details at scala-internals:
https://groups.google.com/forum/#!topic/scala-internals/hcnUFk75MgQ
SI-6840 fixes weird typing of quasiquote arguments

Previously quasiquote arguments were type checked against Any
which caused weird inference that made splicing of complex expressions
unusable:

   val l1 = List(q"foo")
   val l2 = List(q"bar")
   q"f(..${l1 ++ l2})" // argument type checked as Any instead of List[Tree]

This is fixed by forcing compiler to type check against type
variable which itself isn't used in any other way.
SI-7519: Additional test case covering sbt/sbt#914
Platform independence for SI-6240 test case

File.pathSeparator, rather than ":"
Merge pull request #3064 from retronym/topic/broken-windows2

Platform independence for  test case
SI-7295 Fix windows batch file with args containing parentheses

In command scripts, substitution of `FOO` in `if cond ( %FOO% )` happens
*before* the condition is evaluated. One can use delayed expansion with
`if cond (!FOO!)` to get a saner behaviour. Or, as I ended up doing here,
use a goto in the body of the if rather than referring directly to variables
there.

Here's a cut down version to demonstrate the old problem:

    C:\Users\IEUser>type test.cmd
    @echo off

    setlocal enableextensions enabledelayedexpansion

    if [%~1]==[-toolcp] (
      set CP=%~2
      shift
      shift
    )
    echo -toolcp %CP%
    echo %~1 %~2

    C:\Users\IEUser>test.cmd a b
    -toolcp
    a b

    C:\Users\IEUser>test.cmd -toolcp "c:\program files" a b
    -toolcp c:\program files
    a b

    C:\Users\IEUser>test.cmd -toolcp "c:\program files" "a()b" "c()d"
    -toolcp c:\program files
    a()b c()d

    C:\Users\IEUser>test.cmd "a()b" "c()d"
    d was unexpected at this time.

I don't understand exactly why the parentheses only mess things
up in this situation. But regardless, lets find another way.

My first attempt to fix this was based on the suggestion in the ticket.
But, as shown below, this fails to capture the -toolcp.

    C:\Users\IEUser>type test.cmd
    @echo off

    setlocal enableextensions enabledelayedexpansion

    if [%~1]==[-toolcp] (
      set CP=!2!
      shift
      shift
    )
    echo -toolcp %CP%
    echo %~1 %~2
    C:\Users\IEUser>test.cmd "a()b" "c()d"
    -toolcp
    a()b c()d

    C:\Users\IEUser>test.cmd -toolcp "c:\program files" "a()b" "c()d"
    -toolcp
    a()b c()d

Last stop was the goto you'll find in this patch.

With this patch applied, I tested on Windows 8 with the following:

    C:\Users\IEUser>type Desktop\temp.cmd
    ::#!
    @echo off
    call scala %0 %*
    goto :eof
    ::!#
    println("hello, world")
    println(argv.toList)

    C:\Users\IEUser>scala Desktop\temp.cmd "foo(bar)baz"
    "java" -Xmx256M -Xms32M -Dscala.home="C:\PROGRA~3\scala\bin\.."
    -Denv.emacs="" -Dscala.usejavacp=true  -cp "..."
    scala.tools.nsc.MainGenericRunner Desktop\temp.cmd "foo(bar)baz"

    hello, world
    List(foo(bar)baz)

    C:\Users\IEUser>scala -toolcp "c:\program files" Desktop\temp.cmd "foo(bar)baz"
    "java" -Xmx256M -Xms32M -Dscala.home="C:\PROGRA~3\scala\bin\.."
     -Denv.emacs="" -Dscala.usejavacp=true  -cp "...;c:\program files"
     scala.tools.nsc.MainGenericRunner  -toolcp "c:\program files" Desktop\temp.cmd "foo(bar)baz"

    hello, world
    List(foo(bar)baz)
Moving disabled tests to their rightful home.

  test/disabled, not test/files/disabled.
Correct license to 3-clause BSD in poms.
Merge pull request #3067 from retronym/ticket/7020-2

Moving disabled tests to their rightful home.
Clarify comment.