Merge pull request #3484 from retronym/ticket/8237

SI-8237 Avoid cyclic constraints when inferring hk type args
Merge pull request #3471 from adriaanm/t6169

SI-6169 Refine java wildcard bounds using corresponding tparam
Merge pull request #3470 from demobox/si-8215-follow-up

SI-8215: Correcting typo and splitting a long sentence in MatchIterator doc
Merge pull request #3476 from retronym/ticket/8207

SI-8207 Allow import qualified by self reference
Merge pull request #3433 from rjolly/si-7933

SI-7933 REPL javax.script eval is cached result
SI-6169 TODO: consolidate with fix for SI-1786 (#2518)
Merge pull request #3487 from andy128k/master

fix typo
SI-6260 Avoid double-def error with lambdas over value classes

Post-erasure of value classs in method signatures to the underlying
type wreaks havoc when the erased signature overlaps with the
generic signature from an overriden method. There just isn't room
for both. But we *really* need both; callers to the interface method
will be passing boxed values that the bridge needs to unbox and
pass to the specific method that accepts unboxed values.

This most commonly turns up with value classes that erase to
Object that are used as the parameter or the return type of
an anonymous function.

This was thought to have been intractable, unless we chose
a different name for the unboxed, specific method in the
subclass. But that sounds like a big task that would require
call-site rewriting, ala specialization.

But there is an important special case in which we don't need
to rewrite call sites. If the class defining the method is
anonymous, there is actually no need for the unboxed method;
it will *only* ever be called via the generic method.

I came to this realisation when looking at how Java 8 lambdas
are handled. I was expecting bridge methods, but found none.
The lambda body is placed directly in a method exactly matching
the generic signature.

This commit detects the clash between bridge and target,
and recovers for anonymous classes by mangling the name
of the target method's symbol. This is used as the bytecode
name. The generic bridge forward to that, as before, with
the requisite box/unbox operations.
SI-6260 Adddress pull request review

  - fix typo
  - remove BRIDGE flag from the method that we promote from
    a bridge to a bona-fide method
  - note possibility for delambdafy to avoid the bridge method
    creation in *all* cases.
  - note inconsistency with anonymous class naming between
    `-Ydelamdafy:{inline,method}`
Merge pull request #3409 from xeno-by/ticket/6411

SI-6411 SI-7328 value class fixes for runtime reflection
standardizes prefixes used in named/default desugaring
standardizes checks for default getters
deduplication in Symbol.nameString

Since now it uses idString to print out the id part of the name when
-uniqid is turned on, instead of duplicating the code from idString.
introduces -Yshow-symowners

This facility, along with -Yshow-syms, has proven to be very useful
when debugging problems caused by corrupt owner chains when hacking on
named/default argument transformation.
SI-5920 enables default and named args in macros

When producing an initial spec for macros two years ago, we sort of glossed
over named/default arguments in macro applications, leaving them for future work.

Once the aforementioned future has come, I’ve made several attempts at
making things operational (e.g. last summer), but it’s always been unclear
how to marry the quite complex desugaring that tryNamesDefaults performs
with the expectations of macro programmers to see unsugared trees
in macro impl parameters.

Here’s the list of problems that arise when trying to encode named/default
arguments of macro applications:
1) When inside macro impls we don’t really care about synthetic vals
that are typically introduced to preserve evaluation order in non-positional
method applications. When we inline those synthetics, we lose information
about evaluation order, which is something that we wouldn’t like to lose
in the general case.
2) More importantly, it’s also not very exciting to see invocations of
default getters that stand for unspecified default arguments. Ideally,
we would like to provide macro programmers with right-hand sides of those
default getters, but that is: a) impossible in the current implementation
of default parameters, b) would anyway bring scoping problems that we’re
not ready to deal with just yet.

Being constantly unhappy with potential solutions to the aforementioned
problems, I’ve been unable to nail this down until the last weekend,
when I realized that: 1) even though we can’t express potential twists in
evaluation order within linearly ordered macro impl params, we can use
c.macroApplication to store all the named arguments we want, 2) even though
we can’t get exactly what we want for default arguments, we can represent
them with EmptyTree’s, which is not ideal, but pretty workable. That’s
what has been put into life in this commit.

As a pleasant side-effect, now the macro engine doesn’t have to reinvent
the wheel wrt reporting errors about insufficient arg or arglist count.
Since this logic is intertwined with the tryNamesDefaults desugaring,
we previously couldn’t make use of it and had to roll our own logic
that checked that the number of arguments and parameters of macro applications
correspond to each other. Now it’s all deduplicated and consistent.
SI-8226 Deduplicate Scala's Tokens and JavaTokens
Merge pull request #3406 from xeno-by/ticket/7570

SI-7570 top-level codegen for toolboxes
Make handling of tuples more consistent in quasi-quotes

On one hand we know that q"($expr)" is the same as q"$expr". On the
other if we wrap it into a list and splice as q"(..$expr)" we get a
Tuple1 constructor call which is inconsistent.

This pull request fixes this inconsistency by making q"(..$expr)" being
equivalent q"(${expr.head})" for single-element list.

We also add support for matching of expressions as single-element tuples
(similarly to blocks) and remove liftables and unliftables for Tuple1
(which aren't clearly defined any longer due to q"(foo)" == q"foo"
invariant).
SI-8258 Revert "SI-7335 Remove special case for import of Predef._

This reverts commit 66904556ef34dc81cbb7c09257b013b3ddb76f78.

Conflicts:
    src/reflect/scala/reflect/internal/TreeInfo.scala

As evidenced by the highlights of the stack trace in Scala IDE,
my assertion in the 66904556e wasn't universally true.

The change was only motivated by removing a special case, not in
order to fix some other problem. So the revert is the most straight
forward course of action for now.

I haven't pinned this down with a test outside of Eclipse, and
given the lateness of the hour wrt 2.11.0, I'll have to submit
without one.

    2013-03-10 08:38:04,690 ERROR [main] - org.scala-ide.sdt.core - org.scala-ide.sdt.core - org.scala-ide.sdt.core - 0 - Error during askOption
    scala.reflect.internal.Symbols$CyclicReference: illegal cyclic reference involving object Predef
    ...
    at scala.reflect.internal.Symbols$Symbol.lock(Symbols.scala:482)
    at scala.reflect.internal.Symbols$Symbol.info(Symbols.scala:1216)
    at scala.reflect.internal.Symbols$Symbol.tpe(Symbols.scala:1200)
    at scala.reflect.internal.Symbols$Symbol.tpeHK(Symbols.scala:1201)
    at scala.reflect.internal.Types$Type.computeMemberType(Types.scala:784)
    at scala.reflect.internal.Types$Type.memberType(Types.scala:781)
    at scala.reflect.internal.TreeGen.mkAttributedSelect(TreeGen.scala:203)
    ...
    at scala.reflect.internal.TreeGen.mkAttributedStableRef(TreeGen.scala:162)
    at scala.tools.nsc.ast.TreeGen.mkWildcardImport(TreeGen.scala:39)
    at scala.tools.nsc.typechecker.Contexts$Context.makeNewImport(Contexts.scala:308)
    at scala.tools.nsc.typechecker.Contexts$class.rootContext(Contexts.scala:69)
    at scala.tools.nsc.Global$$anon$1.rootContext(Global.scala:492)
    at scala.tools.nsc.typechecker.Contexts$class.rootContext(Contexts.scala:64)
    at scala.tools.nsc.Global$$anon$1.rootContext(Global.scala:492)
    at scala.tools.nsc.typechecker.Analyzer$namerFactory$$anon$1.apply(Analyzer.scala:43)
    at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:463)
    ...
    at scala.tools.nsc.Global$Run.compileLate(Global.scala:1681)
    at scala.tools.nsc.Global$Run.compileLate(Global.scala:1671)
    at scala.tools.nsc.symtab.SymbolLoaders$SourcefileLoader.doComplete(SymbolLoaders.scala:284)
    at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:187)
    at scala.reflect.internal.Symbols$Symbol.info(Symbols.scala:1229)
    at scala.reflect.internal.Symbols$Symbol.tpe(Symbols.scala:1200)
    at scala.reflect.internal.Symbols$Symbol.tpeHK(Symbols.scala:1201)
    at scala.reflect.internal.Types$Type.computeMemberType(Types.scala:784)
    at scala.reflect.internal.Types$Type.memberType(Types.scala:781)
    at scala.reflect.internal.TreeGen.mkAttributedSelect(TreeGen.scala:203)
    at scala.reflect.internal.TreeGen.mkAttributedRef(TreeGen.scala:124)
    at scala.reflect.internal.TreeGen.mkAttributedRef(TreeGen.scala:130)
    at scala.reflect.internal.TreeGen.mkAttributedStableRef(TreeGen.scala:162)
    at scala.tools.nsc.ast.TreeGen.mkWildcardImport(TreeGen.scala:39)
    ...
    at scala.tools.nsc.Global$$anon$1.rootContext(Global.scala:492)
    at scala.tools.nsc.typechecker.Analyzer$namerFactory$$anon$1.apply(Analyzer.scala:43)
    at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:463)
    ...
    at scala.tools.nsc.Global$Run.compileLate(Global.scala:1671)
    at scala.tools.nsc.symtab.SymbolLoaders$SourcefileLoader.doComplete(SymbolLoaders.scala:284)
    at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:187)
    at scala.reflect.internal.Symbols$Symbol.info(Symbols.scala:1229)
    at scala.reflect.internal.Symbols$Symbol.initialize(Symbols.scala:1365)
    ...
    at scala.collection.immutable.HashSet$HashSet1.foreach(HashSet.scala:153)
    at scala.collection.immutable.HashSet$HashTrieSet.foreach(HashSet.scala:306)
    at scala.tools.eclipse.javaelements.ScalaJavaMapper$class.initializeRequiredSymbols(ScalaJavaMapper.scala:29)
    ...
    at scala.tools.nsc.util.InterruptReq.execute(InterruptReq.scala:26)
    at scala.tools.nsc.interactive.Global.pollForWork(Global.scala:340)
Start the PC thread only after initialization of required symbols.

If the class path is incomplete, the presentation compiler might crash during construction.
If the PC thread was already started, it will never get the chance to shutdown, and the
thread leaks. In the IDE, where the PC is started when needed, this can lead to a very
quick depletion of JVM threads.

See Scala IDE #1002016.