A curious effect caused by type tags being moved to scala-reflect.jar

[Eugene Burmako]

Hi folks,

Since tonight scala.reflect.base has been removed, and its inhabitants
have moved to scala.reflect.api into scala-reflect.jar.

This made sbt build go boom http://groups.google.com/group/scala-internals/browse_thread/thread/166ce4b71b7c46bb,
but luckily there's an easy fix: https://github.com/scala/scala/pull/1360.

What's interesting though is the implications of the refactoring
uncovered by the aforementioned crash. Suppose we have a library L and
an application A that depends on L. Also suppose that the only two
dependencies of A are L and scala-library.jar (i.e. no scala-
reflect.jar). Let's study a few scenarios:

1) L doesn't use type tags. Then, since A doesn't depend on scala-
reflect.jar in any way, we're fine (after my pull request gets
accepted).

2) L ascribes some of its methods with type tags, A uses these
methods. Then, if anyone tries to compile A with only scala-library
and L on the classpath, scalac will try to materialize type tags for
the usages, which is impossible since we don't have scala-reflect.jar
on the classpath. Therefore, we'll get a compilation error. However,
build tools are capable of figuring out the transitive dependency on
scala-reflect.jar, so we're fine again.

3) L exposes some type tags into implicit scope (e.g. by declaring an
implicit val of type TypeTag[T] in an object). A imports these
implicits and performs a manifest lookup. Scalac contains facilities
that can synthesize manifests from type tags, but these facilities are
now in scala-reflect.jar. Therefore, if anyone tries to compile A with
only scala-library and L on the classpath, it will be a compilation
error. But again, build tools would probably figure out a transitive
dependency, so we're fine.

Bottom line. In some situations a transitive dependency on scala-
reflect.jar might lead to unexpected compilation errors, when type
tags are involved. But it looks like that build tools should be
capable to take care of that. Right?

[Grzegorz Kossakowski]

I believe yes. This is not very different from any other dependency. Say if L1 that defines some trait and then L depends on it. If you try to compile A without having L1 on your compilation classpath compiler will produce an error because you'll be missing symbol for trait defined in L1 that L depends on (like in a method that you are trying to call). I don't see how TypeTags are different here.

The only question is if error messages are understandable? In case of missing symbol for some trait we know what to expect. What about missing scala-reflect.jar where TypeTag facilities are defined?

--
Grzegorz Kossakowski

[Eugene Burmako]

Now when the hotfix is being tested, I'll check scenarios #2 and #3
and will make sure that the error messages are correct.

On Sep 20, 11:40 am, Grzegorz Kossakowski
<grzegorz.kossakow...@gmail.com> wrote:

> On 20 September 2012 11:33, Eugene Burmako <eugene.burm...@epfl.ch> wrote:
>
>
>
>
>
>
>
>
>
> > Hi folks,
>
> > Since tonight scala.reflect.base has been removed, and its inhabitants
> > have moved to scala.reflect.api into scala-reflect.jar.
>
> > This made sbt build go boom

> >http://groups.google.com/group/scala-internals/browse_thread/thread/1...
> > ,

[martin]

I think your analysis is correct, Eugene. As long as we get compilation errors, we are fine. No show-blocker I can make out.

 - Martin