search

scala / scala-dev

Scala 2 team issues. Not for user-facing bugs or directly actionable user-facing improvements. For build/test/infra and for longer-term planning and idea tracking. Our bug tracker is at https://github.com/scala/bug/issues
Apache License 2.0
130 stars 14 forks source link

Avoid loading symbols that are not strictly needed #463

Open adriaanm opened 6 years ago

adriaanm commented 6 years ago

In the context of build tools like bazel, act more like javac to hide transitive dependency (e.g. coding against interface, should not need to load impl.)

based on hallway discussion with @johnynek -- this ticket needs fleshing out before we can start work on it

retronym commented 6 years ago

The specialization info transformer is one place that forces more infos than desired (the base classes of any types in an info-transformable location are searched).

Another one is erasure, which needs to force infos to check for AnyVal parentage.

new Foo will compute the base classes (forcing infos on the way up) of Foo to find the member <init> (even though constructors aren't inherited).

ClassfileParser should probably use lazy types for members. WIP: https://github.com/scala/scala/pull/5308

retronym commented 6 years ago

In summary: some of the extra exploration of transitive deps might be inherently required to implement some of Scala's language features, some parts are just artifacts of the implementation that are easier to fix.

smarter commented 6 years ago

ClassfileParser should probably use lazy types for members. WIP: scala/scala#5308

That sounds interesting, why was the PR closed?

retronym commented 6 years ago

I wasn't willing to risk making the classfile parser lazy if it meant that we would retain the contents of every accessed, Java-defined classfile in memory (the lazy type completers would need access to the constant pool, which is currently backed by the entire Array[Byte] of the class contents). My quick attempt in to avoid that problem (d9e22cbee9f6d6e064da268da72e4124c6901c04) failed, and I need to come back to it.

retronym commented 6 years ago

IIRC, the main reason that the non-lazy classfile parser forces infos is to form TypeRef-s to inner classes. We don't have a way to refer to Foo$Bar without forcing Foo. I believe that Javac has a different design here that we might be able to learn from.

SethTisue commented 4 years ago

for context, see https://github.com/scala/scala/pull/5724 and https://github.com/scalacenter/advisoryboard/blob/master/proposals/009-improve-direct-dependency-experience.md