2017-07-24 4 views
4

J'ai une caisse A qui dépend de B et B dépend de rust-nmea caisse.construction de la cargaison du même code: fausses erreurs de compilation?

Si je construis caisse A Je suis tas d'erreurs (tous qui a manqué use std::error::Error;) lors de la construction de rust-nmea dépendance:

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;` 

Mais si je vais à l'arbre source de B caisse et exécuter cargo build, tout construire sans erreur (si vous suivez-moi A dépendent de B et B dépendent rust-nmea),

également si aller à /home/evgeniy/.cargo/registry/src/github.com-1ecc6299db9ec823/nmea-0.0.6/ (voir com erreur de pile) et exécutez cargo build alors tout va bien.

spectacle arbre cargo

pour 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 (*) 

et mis en cache par 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 (*) 

donc à la fois bon et mauvais cas a utilisé les mêmes dépendances.

Si exécuté cargo build -v -j1, j'ai obtenu rustc ligne de commande pour les deux cas.

La seule différence pour le bien et le mauvais cas est cette partie:

-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 

mauvais cas ont autre chemin aux bibliothèques et libnom-e2ec53418967eac0.rlib au lieu de libnom-b72336f662b090c1.rlib, alors que libchrono-8e9e54e691d9b988.rlib partie.

Les caisses A et B sont de source proche et je ne peux pas réduire le problème à un cas plus simple. nom caisses non utilisées dans A et B sauf via rust-nmea. rust-nmea est utilisé de manière simple, juste nmea = 0.0.6 dans Cargo.toml. Pas de drapeaux ou autres choses.

Une idée de pourquoi la dépendance de la caisse avec les mêmes drapeaux (pas de drapeaux du tout) peut produire ou non une erreur de syntaxe?

+0

Aveuglement dans l'obscurité: utilisez-vous de la rouille, et si oui, avez-vous défini des remplacements locaux qui pourraient interférer? –

+0

@DK. Oui j'ai utilisé 'rustup', mais la dernière commande override était:' grep -a override ~/.bash_history | Grep Rustup | queue -n 1' 'rustup override unset'. Un moyen de vérifier si 'override' est toujours actif? – fghj

+0

Il y a 'liste de remplacement rustup'. –

Répondre

2

Je trouve la source de problème, caisse A a deuxième niveau dependicies avec cexpr, cexpr a nom = {version = "^3", features = ["verbose-errors"] } dans Cargo.toml, rust-nmea aussi dépendent nom, nous avons donc erreur de compilation de temps.