reflection API compatibility with 2.10.x

This is just one of the possible strategies for compatibility with
reflection API of 2.10.x family. Here’s the discussion:

1) Do nothing.

Document the fact that we’ve organized internal APIs in a separate module
and let people figure out themselves.

Pros: no boilerplate on our side.
Cons: potential for confusion, major upfront migration effort.

2) (This commit). Introduce a compatibility pack with a manual import.
Compatibility pack lives in a separate module that has to be manually imported.
People will get compilation errors when trying to compile macros using
internal APIs against 2.11, but those will be quenched by a single
`import compat._` import. Compatibility stubs would still produce
deprecation warnings, but people can choose to ignore them to alleviate
migration costs.

Pros: brings attention of the users to the fact that they are using
internal APIs by providing a more powerful nudge than just deprecation.
Cons: even though migration effort is trivial, it is still non-zero.

3) Deprecate internal APIs in-place.

Pros: zero migration effort required.
Cons: those who ignore deprecations will be unaware about using internal APIs,
there will be some naming conflicts between Universe.xxxType and internal.xxxType
type factories.

1 files changed, 1 insertions, 0 deletions

diff --git a/src/reflect/scala/reflect/runtime/JavaUniverseForce.scala b/src/reflect/scala/reflect/runtime/JavaUniverseForce.scala
index be8a2865d3..01655bdb54 100644
--- a/src/reflect/scala/reflect/runtime/JavaUniverseForce.scala
+++ b/src/reflect/scala/reflect/runtime/JavaUniverseForce.scala
@@ -31,6 +31,7 @@ trait JavaUniverseForce { self: runtime.JavaUniverse  =>
     this.rootMirror
     this.traceSymbols
     this.perRunCaches
+    this.compat
     this.treeBuild
     this.FreshNameExtractor
     this.FixedMirrorTreeCreator