为什么scalac需要对类路径的传递依赖 [英] Why does scalac need a transitive dependency on the classpath

问题描述

我正在遇到一个意想不到的（仅对我而言）ScalaC行为。

TL; DR是以下是在尝试从maven迁移代码库时看到的问题去b。这种迁移的主要重点之一是尝试最小化每个类对编译所需的依赖性，以便只有在需要时才会触发构建。

不幸的是，我看到的是给定 ClassIndirectlyNeedingFoo （uses） - > ClassUsingFoo （用途） - > 供应商 ClassIndirectlyNeedingFoo 的汇编如果 不在类路径上。
完整的详细信息在这里（ https://github.com/ittaiz/scalac-troubleshooting ）。

如果有人知道为什么scalac的行为像这样，我真的很感激。

谢谢！

BTW，供应商不在ClassIndirectlyNeedingFoo的源代码或字节码...

解决方案

好的，所以简短的答案是code>为什么不完全清楚任何人（见＃4）。很明显的是，已知scalac有时需要更多的依赖关系，而且也很清楚，有时候，当这种情况发生时，它是一个 bug 。

此外，从与Jason Zaugg的讨论 Gitter 他似乎认为我的上述问题只是一个类似于上面链接的错误家庭。

由于Seth与评论相关联， ScalaCenter 已接受提案（原始公关），以澄清这个地区。

与此问题最相关的是四项建议：

1. 改进针对stub错误的用户体验，围绕语句：它们是预期的常见情况，而不是
   罕见，意外或致命的条件。


2. 减少导致存根错误的案例数量...即，允许更多的使用目前导致存根错误的用例
   成功编译，从而允许更少的直接依赖。


3. 一个编译器标志，要求编译期间使用的所有符号的 import 包括没有在
   源中另外提到的那些）。为了与 -Ywarn-unused-imports 对称，此选项可能
   可能被称为 -Ywarn-undeclared-imported 。它主要是
   协助从转换到直接
   依赖关系，而不是帮助维护已经
   使用直接依赖关系的构建。 （如
   @posco和
   的建议 @adriaanm ）


4. 扩展Scala语言规范以列出所有案例，其中来自另一个编译单元的符号必须存在于
   类路径上，包括：1）子类化，2）超类的返回类型
   公共方法，3）直接引用，4）等。

这是同意继续＃3，虽然我不知道什么时候开始工作。

Eugeene Burmako，谁共同撰写了该提案，开始构建解决方案的原型，我已经做了一个小的更改。

现在这将对我的问题有所帮助。 p>

I'm running into an unexpected (only for me?) ScalaC behavior.
The TL;DR is that the following is a recreation of an issue I saw while trying to migrate a codebase from maven to bazel. One of the main focuses of this migration is to try to minimize the dependencies each class needs for compilation so that builds will be triggered only when needed.

Unfortunately what I saw is that given ClassIndirectlyNeedingFoo(uses)->ClassUsingFoo(uses)->Supplier the compilation of ClassIndirectlyNeedingFoo breaks if Supplier is not on the classpath. The full details are here (https://github.com/ittaiz/scalac-troubleshooting).
If anyone knows why scalac behaves like this I'd really appreciate it.
Thanks!

BTW, Supplier is not in the source or bytecode of ClassIndirectlyNeedingFoo...

解决方案

Ok so the short answer is that Why isn't totally clear to anyone (see #4). What is clear is that it's known scalac sometimes needs more dependencies than one would think and it's also clear that sometimes when this happens it's a bug.

Furthermore from a discussion with Jason Zaugg on Gitter he seems to think my above issue is just apart of a family of bugs like the one linked above.

As Seth linked in the comments the ScalaCenter has accepted a proposal (original PR) for clarifying this area.
Most related to this issue are the four proposals there:

1. Improvements to the user experience of stub errors, centered around the Statement: that they are an expected common case, rather than a rare, unexpected, or fatal condition.
2. Reduction of the number of cases that result in stub errors... ie, allowing more usecases that currently result in a stub error to successfully compile, and thus allowing for fewer direct dependencies.
3. A compiler flag to require import statements for all symbols used during compilation (including those not otherwise mentioned in the source). For symmetry with -Ywarn-unused-imports, this option might potentially be called -Ywarn-undeclared-imports. It would primarily assist with making the transition from transitive to direct dependencies, rather than helping to maintain a build that is already using direct dependencies. (as suggested by @posco and @adriaanm)
4. An expansion of the Scala Language Specification to list all cases in which a symbol from another compilation unit must be present on the classpath, including: 1) subclassing, 2) return types of superclasses' public methods, 3) direct reference, 4) etc.

It was agreed to go ahead with #3 though I don't know when the work will commence.
Eugeene Burmako, who co-authored the proposal, started prototyping the solution and I've made a small change on top of that.
For now this will have to do for my problem.

这篇关于为什么scalac需要对类路径的传递依赖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！