Scaladoc: fixing small typo in PartialFunction.scala

Fixing a one-letter typo in the documentation of PartialFunction.scala (from "an plain" to "a plain").
fixes a crash in ReflectionUtils.systemProperties

Due to SI-7465 we were erroneously assuming that System.getProperties
only contains string key and string values. This led to a CCE when there
was something else.
removes the traces of always on debug diagnostics

pun intended
replaces inferBootClasspath with a simple lookup at sun.boot.class.path

It's not like we're achieving any generality by iterating through all
keys in System.getProperties and looking for ones which resemble
"boot.class.path", so let's be simpler.
pull request feedback
[nomaster] temporarily breaks SI-5353

The subsequent fix to SI-5923 unmasks the fact that SI-5353 has not
been fixed - it's just that one of its manifestation got hidden behing
SI-5923. In fact, if in the code snippet from the bug report we change
Array() to Array[Nothing](), things will start crashing as usual.

The problem we have here is that arrays of nothings and nulls are very
weird in a sense that their compile-time representations (types) and
their runtime representations (JVM arrays of Object) behave differently
with respect to subtyping. Due to an unlucky coincidence SI-5923 prevented
some of the arrays of nothing from being compilable, so the problem was
well hidden until now.

A principled approach to handling the situation we have here would be to
fix SI-5353 (we already know how to do that: https://github.com/scala/scala/pull/2486)
and to disallow arrays of nothings and nulls as suggested in SI-7453.
Unfortunately, both fixes are going to bring incompatibilities, which are
not acceptable in a minor release (this pull request targets 2.10.x).

Therefore we decided to turn a blind eye on the iceberg and just fix a tip
of it by emulating the portion of SI-5923 that used to mask SI-5353, retaining
perfect backward compatibility.

Unfortunately, it's not that easy. Apparently one cannot simply report
all the occurrences of Array() as errors, because if we know expected type
of that expression, then everything's fine - the expected type will drive type
inference and the dreaded Array[Nothing]() will not arise. All right,
so let's just check whether pt == WildcardType and then report errors.
However that's still not enough because of SI-3859.

Having my hack failing for the third time, made me stop for a second and
think whether it's worth to play with fire and introduce potential
breakages for the sake of preventing a quite unlikely bug from happening.
I don't think the it's okay to risk here, therefore I just disable the
failing test, especially because we already have a working fix to SI-5353
submitted to master, so it's not like we're deferring the work to be done
to a random point in unclear future.

NOTE: That's only a temporary hack targeted at 2.10.x. There's no
reason for this code to be merged into master, because master is soon
going to have a principled solution to the problem:
https://github.com/scala/scala/pull/2486.
[nomaster] SI-5923 instantiates targs in deferred macro applications

Amazingly enough, the fix for the "macro not expanded" problem was super
easy. (And I remember spending a day or two trying to find a quick fix
somewhen around Scala Days 2012!)

The problem was in the implementation of the macro expansion trigger,
which was buried in a chain of if-elif-elif in `adapt`. This meant that macro
expansion was mutually exclusive with a lot of important adaptations, e.g.
with `instantiate`.

More precisely, if an expandee contains an undetparam, its expansion
should be delayed until all its undetparams are inferred and then retried
later. Sometimes such inference can only happen upon a call to instantiate
in one of the elif's coming after the macro expansion elif. However this
elif would never be called for expandees, because control flow would always
enter the macro expansion branch preceding the inference branch.

Therefore `macroExpand` now takes the matters in its own hands,
calling `instantiate` if the expansion has been delayed and we're not in
POLYmode (see a detailed explanation in a comment to `macroExpand`).

Consequences of this fix are vast. First of all, we can get rid of the
"type parameter must be specified" hack. Secondly and most importantly,
we can now remove the `materializeImplicit` method from Implicits and
rely on implicit macros to materialize tags for us. (This is a tricky
change, and I'll do it later after we merge as much of my pending work
as possible). Finally, we learn that the current scheme of interaction
between macros, type inference and implicits is, in principle, sound!

NOTE: This patch is a second take on fixing implicit macros, with the first
one being a backport from macro paradise merged into master in January 2013:
https://github.com/scala/scala/commit/fe60284769.

The original fix had an unfortunate error, as described on scala-internals:
https://groups.google.com/forum/#!msg/scala-internals/7pA9CiiD3u8, so I had
to refine the approach here.

This means that it's not possible to directly merge this commit into master,
so I'm marking it as [nomaster] and will submit a separate pull request
targetting master later on.
[nomaster] macroExpandAll is now triggered in all invocations of typed

macroExpandAll is the key player in the mechanism of expanding macros after
their type arguments have been inferred. (Macro applications that contain
yet uninferred type arguments don't get expanded and are delayed until
the targs are inferred. Therefore later on we need to trigger those delayed
expansions manually, which is done by macroExpandAll).

Previously macroExpandAll was only called from a few selected places in
the typechecker, but that's quite risky, since typer evolves, and who knows
when this scheme breaks.

To make things more robust, I'm now calling macroExpandAll in the epilogue
of every single call to `typed`. Don't worry - this shouldn't impose
noticeable performance penalties, since the call is guarded by a branch
upon a plain boolean field.

NOTE: This patch is a second take on fixing implicit macros, with the first
one being a backport from macro paradise merged into master in January 2013:
https://github.com/scala/scala/commit/fe60284769.

The original fix had an unfortunate error, as described on scala-internals:
https://groups.google.com/forum/#!msg/scala-internals/7pA9CiiD3u8, so I had
to refine the approach here.

This means that it's not possible to directly merge this commit into master,
so I'm marking it as [nomaster] and will submit a separate pull request
targetting master later on.
[nomaster] SI-7167 implicit macros decide what is divergence

Imagine a macro writer which wants to synthesize a complex implicit
Complex[T] by making recursive calls to Complex[U] for its parts.

E.g. if we have `class Foo(val bar: Bar)` and `class Bar(val x: Int)`,
then it's quite reasonable for the macro writer to synthesize
Complex[Foo] by calling `inferImplicitValue(typeOf[Complex[Bar])`.

However if we didn't insert `info.sym.isMacro` check in `typedImplicit`,
then under some circumstances (e.g. as described in http://groups.google.com/group/scala-internals/browse_thread/thread/545462b377b0ac0a)
`dominates` might decide that `Bar` dominates `Foo` and therefore a
recursive implicit search should be prohibited.

Now when we yield control of divergent expansions to the macro writer,
what happens next? In the worst case, if the macro writer is careless,
we'll get a StackOverflowException from repeated macro calls. Otherwise,
the macro writer could check `c.openMacros` and `c.openImplicits` and
do `c.abort` when expansions are deemed to be divergent. Upon receiving
`c.abort` the typechecker will decide that the corresponding implicit
search has failed which will fail the entire stack of implicit searches,
producing a nice error message provided by the macro writer.

NOTE: the original commit from macro paradise also introduced a new
class, which encapsulates information about implicits in flight.
Unfortunately we cannot do that in 2.10.x, because of binary compatibility
concerns, therefore I'm marking this commit as [nomaster] and will be
resubmitting its full version in a separate pull request exclusively
targetting master.
[nomaster] SI-7291: No exception throwing for diverging implicit expansion

Since we don't throw exceptions for normal errors it was a bit odd
that we don't do that for DivergingImplicit.
As SI-7291 shows, the logic behind catching/throwing exception
was broken for divergence. Instead of patching it, I rewrote
the mechanism so that we now another SearchFailure type related
to diverging expansion, similar to ambiguous implicit scenario.
The logic to prevent diverging expansion from stopping the search
had to be slightly adapted but works as usual.

The upside is that we don't have to catch diverging implicit
for example in the presentation compiler which was again showing
that something was utterly broken with the exception approach.

NOTE: This is a partial backport of https://github.com/scala/scala/pull/2428,
with a fix for SI-7291, but without removal of error kinds (the former is
absolutely necessary, while the latter is nice to have, but not a must,
therefore I'm not risking porting it to 2.10.x). Also, the fix for SI-7291
is hidden behind a flag named -Xdivergence211 in order not to occasionally
break the code, which relies on pre-fix behavior.
[nomaster] SI-7047 fixes silent for c.inferImplicitXXX

silent = true now throws a TypecheckException even if we don't know why
an implicit search has failed (i.e. if context.hasErrors is false).

NOTE: this commit is a part of a pull request for 2.10.x, which makes sense of
implicit macros. Everything in that pull request is [nomaster] due to one
reason or another. This commit would work equally well in both 2.10.x and
master, but I'm marking it as [nomaster] as well, because I'm anyway going
to resubmit the whole pull request into master soon, so there's no reason
to introduce additional confusion.
[nomaster] SI-7166 catches DivergentImplicit in c.inferImplicitXXX

Despite inferImplicit usually being nice and buffering errors, apparently
it can also throw DivergentImplicit exception. This patch catches it and
only reports it if silent is set to false.

NOTE: we no longer have the DivergentImplicit exception in master,
so this commit only makes sense in 2.10.x.
[nomaster] removes duplication in inferImplicitValue

Shame-driven development at its best.
Merge pull request #2505 from scalamacros/topic/macros

some fixes for macros: one esoteric, and one quite critical
Merge pull request #2496 from igormoreno/2.10.x

Scaladoc: fixing small typo in PartialFunction.scala
Merge pull request #2494 from scalamacros/ticket/5923

makes sense of implicit macros!