[nomaster] teaches toolbox about -Yrangepos

Unlike in master, in 2.10.x enabling -Yrangepos requires instantiating
Global with mixed in RangePositions trait.

Same story for toolboxes. Just setting Yrangepos is not enough - one
needs to mix in RangePositions into ToolboxGlobal. I didn’t know that
back then, so now I’m fixing the oversight.

The commit is marked as [nomaster], because -Yrangepos doesn’t need
special treatment in master.
Merge pull request #3196 from retronym/topic/3190-fixup

Corrects positions for Dynamic calls
Merge pull request #3180 from xeno-by/topic/toolbox-rangepos

teaches toolbox about -Yrangepos
SI-7548 askTypeAt returns the same type whether the source was fully or targeted type-checked

When asking for targeted typecheck, the located tree may have overloaded types
is the source isn't yet fully typechecked (e.g., a select tree for an
overloaded method). This is problematic as it can lead to unknown 'hovers',
broken hyperlinking that suddenly starts working, unresolved ScalaDoc comments,
and similar, in the Scala IDE.

With this commit we are hardening the contract of `askTypeAt` to return the
same type whether the file was fully type-checked or targeted type-checked.
This is done by preventing the typechecker to stop too early if the `located`
tree has an overloaded type. Furthermore, I'm assuming that if `located.tpe`
is of type `OverloadedType`, by letting the compiler carry-on the typechecking,
the `located.tpe` will eventually be resolved to a non-overloaded type. Said
otherwise, I expect the targeted typechecking will always terminate (if my
reasoning isn't sound, please say so).

The test provided with this commit demonstrates the new behavior (the position
used to execute the test is resolved to the `foo` method's call). In fact,
before this commit, executing the test returned the following:

    (x: Int, y: String)Unit <and> (x: String)Unit <and> (x: Int)Unit

Showing that the tree's type is an overloaded type. The ambiguity is fixed by
this commit, and in fact the test's output is now:

    (x: Int)Unit
SI-7548 Test to demonstrate residual exploratory typing bug

We shouldn't observe tree types under silent mode.

The enclosed test is a standalone version of `1 + BigInt(2)`,
a standard example of exploratory typing in Scala. Once we determine
that none of the `+` methods in `Int` accepts (possibly implicitly
coerced `BigInt`), we have to backtrack and look for a view from
`Int => { +(_: BigInt): ? }`.

The next commit will correct the problem.
SI-7458 Pres. compiler must not observe trees in silent mode

Otherwise we can think that `+` in `1 + BigInt(2)` refers
to a method in `Int`.

In general, this protects the IDE from observing results from
"exploratory" typing which is discarded as the compiler backtracks
to another possibility.

This protection subsumes the condition that checked for overloaded
types: presentation/t7458 now passes without this.
Merge pull request #3208 from dotta/si-7548-on-2.10

 askTypeAt returns the same type for full/ targeted typecheck (2.10.x)
SI-6913 Fixing semantics of Future fallbackTo to be according to docs

Origin: viktorklang@1bbe854
Merge pull request #3181 from heathermiller/issue/6913

SI-6913 Reapplies a lost fix by @viktorklang
SI-7982 Changed contract of askLoadedType to unload units by default

The rationale for not keeping units loaded by default is that the more
units are loaded, the slower is background compilation. For instance, in
the Scala IDE for Eclipse (which uses the presentation compiler),
typechecking occurs every time the reconciler kicks-in (~500millis after
you stop typing), hence it is important that units are not kept loaded
unless strictly necessary (for some extra information about this, see
https://www.assembla.com/spaces/scala-ide/tickets/1001388)

While I agree that using a boolean argument (`keepLoaded`) for deciding
if a unit should be loaded isn't a great design, other methods in
`CompilerControl` also have a keepLoaded parameter, so at least we have
some consistency. For the future, I'm thinking we should be able to
remove the `keepLoaded` flag altogether, and change the implementation
of `askLoadedType` to preserve the same units loaded in the presentation
compiler before and after its execution. Basically, if you want a unit
to be kept loaded, you should call `askReload` first, and then
`askLoadedType`. However, to reduce impact, I think the changes carried
by this commit will help us estimate if the solution I just outlined is
viable (because `askLoadeType` won't be keeping units loaded by default,
which wasn't the case with the former implementation).

(While the patch was mostly contributed by @huitseeker, @dotta has edited the
commit message to preserve the comments in the PR
https://github.com/scala/scala/pull/3209)
SI-8010 Fix regression in erasure double definition checks

Calls to `Symbol#info` during scope iteration considered harmful.

Looks like calling `info` during this Scope iteration is triggering
the ExplicitOuter info transformer, which "makes all super accessors
and modules in traits non-private, mangling their names.". This name
change necessitates a rehashing of the owning scope, which I suspect
is enough to corrupt the ScopeEntry-s being traversed in
`checkNoDeclaredDoubleDefs`.

The upshot was that we encountered the same symbol twice, which was
reported as being a double-definition.

This problem only showed up after 086702d8a74, which did nothing
worse then change the order in which `{e, e1}.sym.info` were
forced.

I inspected SymbolPairs/OverridingPairs which *appear* to be immune
as they only test flags during scope iteration; infos are not used
until later, at which point we're iterating a temporary scope that
isn't part of the type of the owner of the symbols.
Merge pull request #3209 from dotta/SI-7982-on-2.10.x

 make askLoadedType unload arguments out of the PC by default,
SI-8029 Avoid multi-run cyclic error with companions, package object

The bug report suggests this problem only became visible in the
IDE *after* 2.10.3, but I tested an IDE with exactly 2.10.3 and
saw the same problem.

In fact, my test case fails as far back as 2.10.0. I suspect the
problem showed up after 816cecf9a9, which checks that pairs of
companion symbols are codefined eagerly in Namers.

This commit modifies the check of `rawInfo ne NoType`
in `isCoDefinedWith` to avoid triggering adaptation of types from
the previous run. I'm not sure of the precise intent of that check.
I looked at c9861cd198 (genesis of isCoDefinedWith). Before that we
get back to 3761cb4b3a1 (the dawn of Subversion.)
[nomaster] better error messages for various macro definition errors

backport of 1d3ec4e708154ec05554f540d7d68ed55dc12426
Merge pull request #3232 from xeno-by/topic/macro-error-messages-210x

[nomaster] better error messages for various macro definition errors
[backport] SI-7439 Avoid NPE in `isMonomorphicType` with stub symbols.

`originalInfo` can return null for stub symbols; deal with that
as we used to before a regression in 016bc3db.

After this change, we can once again delete A_1.class and still compile
code instantiating B_1. (A_1 is only referred to in a method signature
of B_1 which is not called from our code.)

	scala> new B_1
	warning: Class A_1 not found - continuing with a stub.
	res0: B_1 = B_1@5284b8f9

In practice, this situation arises when someone uses a third
party class that was compiled against other libraries not avaialable
on the current compilation classpath.

(cherry picked from commit a95432168204964e4f6c4571e781559c1640f2d8)
Merge pull request #3223 from retronym/ticket/8010-2.10.x

SI-8010 Fix regression in erasure double definition checks
Merge pull request #3230 from retronym/backport/7439

[backport] SI-7439 Avoid NPE in `isMonomorphicType` with stub symbols.
Merge pull request #3229 from retronym/ticket/8029

SI-8029 Avoid multi-run cyclic error with companions, package object
SI-8019 Make Publisher check PartialFunction is defined for Event

Reactions are PartialFunctions, so if events come through
indiscriminately that the listener is not defined for, errors occur. Eg:

--
Exception in thread "AWT-EventQueue-0" scala.MatchError: FocusGained(scala.swing wrapper scala.swing.TextField
--

A Coursera thread with people affected by this issue:

https://class.coursera.org/reactive-001/forum/thread?thread_id=1315