Почему скаляк нуждается в транзитивной зависимости от пути к классам

Question

Я столкнулся с неожиданным (только для меня?) Поведением ScalaC.
TL, DR - это то, что следующее - это воссоздание проблемы, которую я видел, пытаясь перенести кодовую базу с maven на bazel. Одним из основных направлений этой миграции является попытка минимизировать зависимости, необходимые каждому классу для компиляции, так что сборки будут запускаться только при необходимости.

К сожалению, то, что я видел в том, что данные ClassIndirectlyNeedingFoo (использование) ->ClassUsingFoo (использует) ->Supplier составление ClassIndirectlyNeedingFoo перерывов, если Supplier не на пути к классам. Полная информация здесь (https://github.com/ittaiz/scalac-troubleshooting).
Если кто-нибудь знает, почему скалак ведет себя так, я бы очень признателен.
Спасибо!

BTW, Поставщик не в источнике или байткод из ClassIndirectlyNeedingFoo ...

Answer 1

ИТАК короткий ответ, что Why не совсем ясно anyone (см # 4). Ясно, что известно, что скаляру иногда требуется больше зависимостей, чем можно было бы подумать, и также ясно, что иногда, когда это происходит, это bug.

Кроме того, из обсуждения с Джейсоном Заугсом на Gitter он, похоже, считает, что мой вышеизложенный вопрос просто отличается от семейства ошибок, подобных тому, что указан выше.

As Seth связывает в своих комментариях ScalaCenter принял (а) proposal (original PR) для уточнения этой ситуации.
Большинство связанных с этим вопросом являются четыре предложения там:

1. Улучшения пользовательского опыта ошибок окурка, сосредоточенных вокруг Statement: что они ожидаемый общий случай, а не редкие, неожиданные , или фатальное состояние.
2. Сокращение числа случаев, которые приводят к ошибкам заглушки ... т. Е. Разрешению большего количества случаев, которые в настоящее время приводят к ошибке заглушки до , и, таким образом, позволяет сократить количество прямых зависимостей.
3. Флаг компилятора, которому требуются import операторы для всех символов, используемых во время компиляции (включая те, которые не упоминаются в источнике ). Для симметрии с -Ywarn-unused-imports эта опция может быть потенциально может называться -Ywarn-undeclared-imports. В первую очередь это помогло бы сделать переход от переходных к прямым зависимостям, а не помогать поддерживать сборку, которая уже с использованием прямых зависимостей. (Как это было предложено @posco и @adriaanm)
4. Расширение спецификации Scala языка перечислить все случаи, в которых символ из другой единицы компиляции должен присутствовать на пути к классам, в том числе: 1) подклассов, 2) возвращение типы публичных методов суперклассов, 3) прямая ссылка, 4) и т.д.

Это было agreed идти вперед с # 3, хотя я не знаю, когда работа начнется.
Eugeene Burmako, соавторство этого предложения, начал прототипирование solution, и я сделал небольшой change поверх этого.
Теперь это должно будет сделать для моей проблемы.