Cargo сборка того же кода: ложные ошибки времени компиляции?

У меня есть ящик A, который зависит от B и B зависит от ящика rust-nmea.

Если я построю ящик A, у меня будет куча ошибок (все они пропустили use std::error::Error;) во время сборки rust-nmea зависимость:

error[E0599]: no method named `description` found for type `nom::Err<&[u8]>` in the current scope
   --> /home/evgeniy/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-0.0.6/src/parse.rs:100:44
    |
100 |                      IError::Error(e) => e.description().to_string(),
    |                                            ^^^^^^^^^^^
    |
    = help: items from traits can only be used if the trait is in scope
    = note: the following trait is implemented but not in scope, perhaps add a `use` for it:
            candidate #1: `use std::error::Error;`

Но если я перейду к дереву исходных текстов B crate и запускаю cargo build, все будет построено без каких-либо ошибок (если вы последуете за мной, A зависят от B, а B зависят от rust-nmea),

также, если перейти к /home/evgeniy/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-0.0.6/ (см. ошибку компиляции) и запустить cargo build, тогда все будет хорошо.

Выставка грузовых деревьев для A:

│   ├── chrono v0.4.0
│   │   ├── num v0.1.40
│   │   │   ├── num-integer v0.1.35
│   │   │   │   └── num-traits v0.1.40
│   │   │   ├── num-iter v0.1.34
│   │   │   │   ├── num-integer v0.1.35 (*)
│   │   │   │   └── num-traits v0.1.40 (*)
│   │   │   └── num-traits v0.1.40 (*)
│   │   └── time v0.1.38
│   │       └── libc v0.2.27
 ├── nmea v0.0.6
    │   ├── chrono v0.4.0 (*)
    │   └── nom v3.2.0
    │       └── memchr v1.0.1 (*)

и для кешированных cargo rust-nmea:

├── chrono v0.4.0
│   ├── num v0.1.40
│   │   ├── num-integer v0.1.35
│   │   │   └── num-traits v0.1.40
│   │   ├── num-iter v0.1.34
│   │   │   ├── num-integer v0.1.35 (*)
│   │   │   └── num-traits v0.1.40 (*)
│   │   └── num-traits v0.1.40 (*)
│   └── time v0.1.38
│       └── libc v0.2.27
└── nom v3.2.0
    └── memchr v1.0.1
        └── libc v0.2.27 (*)

поэтому как для хорошего, так и для плохого случая используются одни и те же зависимости.

Если запустить cargo build -v -j1, я получу rustc командную строку для обоих случаев.

Единственная разница для хорошего и плохого случая заключается в следующем:

-L dependency=/home/evgeniy/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-0.0.6/target/debug/deps --extern chrono=/home/evgeniy/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-0.0.6/target/debug/deps/libchrono-8e9e54e691d9b988.rlib --extern nom=/home/evgeniy/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-0.0.6/target/debug/deps/libnom-b72336f662b090c1.rlib

в плохом случае путь к библиотекам отличается и libnom-e2ec53418967eac0.rlib вместо libnom-b72336f662b090c1.rlib, а libchrono-8e9e54e691d9b988.rlib совпадает.

Ящики A и B поставляются из близких источников, и я не могу свести проблему к более простому случаю. Ящики nom не используются в A и B, кроме как через rust-nmea. rust-nmea используется просто, просто nmea = 0.0.6 в Cargo.toml. Никаких флагов или чего-то подобного.

Любая идея, почему зависимость ящика с одними и теми же флагами (без флагов вообще) может вызывать или не вызывать синтаксическую ошибку?


rust-cargo rust rust-crates
person fghj    schedule 24.07.2017    source источник
comment
Слепой выстрел в темноте: используете ли вы rustup, и если да, то установили ли вы локальные переопределения, которые могут мешать?   -  person DK.    schedule 24.07.2017
comment
@DK. Да, я использовал rustup, но последняя команда отмены была: grep -a override ~/.bash_history | grep rustup | tail -n 1 rustup override unset. Есть ли способ проверить, активен ли override?   -  person fghj    schedule 24.07.2017
comment
Есть rustup override list.   -  person DK.    schedule 24.07.2017
comment
Еще один слепой выстрел: пробовали ли вы cargo clean, а затем cargo update перед повторным запуском cargo build? Хотя с учетом вывода cargo tree это было бы немного удивительно, но это могло быть случаем устаревшей зависимости.   -  person J David Smith    schedule 24.07.2017
comment
@JDavidSmith Да, я делаю чистую перестройку (удален каталог Cargo.lock и target), а также проверяю версию nom через Cargo.lock на случай ошибки cargo tree   -  person fghj    schedule 24.07.2017

Ответы (1)


arrow_upward
2
arrow_downward

Я нашел источник проблемы, ящик A имеет зависимости второго уровня с cexpr, cexpr имеет nom = {version = "^3", features = ["verbose-errors"] } в Cargo.toml, rust-nmea также зависит от nom, поэтому у нас есть ошибка времени компиляции.

person fghj    schedule 24.07.2017