Поскольку эта проблема включает в себя несколько зависимостей, и я не уверен, в каком направлении искать ее воспроизведение, я надеюсь, что это хорошо, если спросить ее, основываясь на конкретном примере c. Более общая закономерность этого вопроса такова: существует цепочка зависимостей user => libExtension => libBase, а libExtension и libBase несовместимы.
В проекте geo-booleanop , мы сталкиваемся с интересной проблемой , которую мы не можем полностью понять. Он включает взаимодействие следующих пакетов:
- гео-типов (
libBase) : базовая библиотека, которая предоставляет базовые c типы, такие как линии, линии, многоугольники и т. д. c. - geo-booleanop (
libExtension) : здание библиотеки поверх гео-типов, расширяющее его с одной новой функциональностью: новая черта BooleanOp, которая имеет функции типа пересечения / объединения / ... и реализована для типа многоугольника из гео-типов. - Любой пользовательский пакет, который объединяет гео-типы и geo-booleanop с намерением использовать черту
BooleanOp для полигонов.
Недавно в пакетных гео-типах произошли серьезные изменения, начиная с версии 0.4 до 0.5, например, он изменил некоторые поля его тип Rect от полей публикации до получателей.
Пакет geo-booleanop еще не адаптирован к этому изменению, т. е. он все еще явно использует эти поля публикации. В настоящее время Cargo.toml geo-booleanop указывает geo-types = "0.4", и попытка увеличить его до 0,5 и выполнение cargo build в geo-booleanop приводит к ошибкам компилятора при доступе к полю pub, как и ожидалось.
Теперь удивительная вещь: при создании пользовательского пакета, который объединяет последние версии geo-types и geo-booleanop, мы видим следующий вывод из cargo build в пользовательском пакете:
$ cargo build
[...]
Compiling geo-booleanop v0.2.1
Compiling geo-types v0.5.0
[...]
error[E0599]: no method named `union` found for type `geo_types::polygon::Polygon<{float}>` in the current scope
--> src/main.rs:21:23
|
21 | let union = poly1.union(&poly2);
| ^^^^^ method not found in `geo_types::polygon::Polygon<{float}>`
Это удивительно потому что:
- Компиляция geo-booleanop v0.2.1 в сочетании с гео-типами v0.5.0 вообще не должна быть возможной, потому что они несовместимы.
- Ошибка об отсутствии метода
union вводит в заблуждение, потому что пользовательский код делает все правильно, чтобы перенести черту BooleanOp в область действия, которая должна обеспечить именно этот метод для полигонов. - По иронии судьбы компилятор также выдает предупреждение о том, что
BooleanOp импорт черт не используется.
Мои вопросы:
- Почему
cargo build не показывает ошибки компиляции, выделите о несовместимости зависимостей? - Если это так, можем ли мы что-нибудь сделать на сайте geo-booleanop, чтобы облегчить такие проблемы для наших пользователей, чтобы gr asp? В настоящее время они все делают правильно с точки зрения написанного кода, чтобы перенести черту в область видимости, и все же компилятор ведет себя так, как будто черта отсутствует - тогда как в действительности это несоответствие версии. Можем ли мы применить более явную ошибку на сайте библиотеки?
Подробности, если они имеют значение:
- Черта
BooleanOp является обобщенной c в ее базовый тип с плавающей точкой ( см. реализацию ). Является ли это причиной проблемы, поскольку генерики не создаются, пока код клиента не использует его, как в других языках программирования? - Это код клиента воспроизведения: main.rs и Car go .томл .