貨物編碼相同的代碼：虛假編譯時錯誤？

我有板條箱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箱的源代碼樹和運行cargo build，所有建立一個沒有任何錯誤（如果你跟着我A取決於B和B取決於rust-nmea），

此外，如果去/home/evgeniy/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-0.0.6/（見COM堆錯誤）並運行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 (*)

和緩存由cargorust-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。沒有標誌等東西。

任何想法爲什麼箱子依賴於相同的標誌（根本沒有標誌）可能產生或不產生語法錯誤？

來源

2017-07-24 fghj

在黑暗中發生盲點：你是否在使用鏽蝕劑，如果是的話，你是否設置了可能會干擾的局部替代物？ –

@DK。是的，我使用了'rustup'，但最後一個覆蓋命令是：'grep -a override〜/ .bash_history | grep rustup | tail -n 1' 'rustup override unset'。任何方式來檢查'覆蓋'仍然活躍？ – fghj

有'鏽蝕覆蓋列表'。 –

我發現了問題的根源，箱A具有二級dependicies與cexpr， cexpr有nom = {version = "^3", features = ["verbose-errors"] }在Cargo.toml， rust-nmea還取決於nom，所以我們有編譯時錯誤。

來源

2017-07-24 17:28:23 fghj

貨物編碼相同的代碼：虛假編譯時錯誤？

回答

相關問題