Cargo test works but doc-test fails with missing crate


#1

Repo for testing here: https://github.com/theindigamer/plex-issue

I’m using the nightly compiler from about a month back (I suppose that shouldn’t make a difference). When I run cargo build, it successfully builds but when I run cargo test it fails with can't find crate for the plex crate.

I ran it with verbose and the problem seems to be with running doc-tests, it says:

running 1 test
test tests::it_works ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

   Doc-tests plex-issue
     Running `rustdoc --test /home/varun/Code/plex-issue/src/lib.rs --crate-name plex_issue -L dependency=/home/varun/Code/plex-issue/target/debug/deps -L dependency=/home/varun/Code/plex-issue/target/debug/deps --extern lalrpop_util=/home/varun/Code/plex-issue/target/debug/deps/liblalrpop_util-54d74d0bd4bcca12.rlib --extern plex_issue=/home/varun/Code/plex-issue/target/debug/deps/libplex_issue-bbd84cf4bc8ab2b6.rlib --extern regex=/home/varun/Code/plex-issue/target/debug/deps/libregex-75ed02f74557cedd.rlib`
error[E0463]: can't find crate for `plex`
 --> /home/varun/Code/plex-issue/src/lib.rs:5:1
  |
5 | extern crate plex;
  | ^^^^^^^^^^^^^^^^^^ can't find crate

error: test failed, to rerun pass '--doc'

Any suggestions on what might be going wrong/how to debug this further? :slightly_frowning_face:


#2

Hard to tell what’s going on here. Your crate looks fine (the duplicate entry of plex under dev-dependencies is redundant though, as is the caret), and the issue sounds very unusual.

I can’t reproduce it without the Cargo.lock, because a breaking change in unstable feature names took place very recently and some—but not all—dependencies have updated. (If I use the current nightly, plex-0.2.2 can’t build because it does not use the new feature names. If I use the same toolchain as you, proc_macro2-0.4.8 can’t build because it did update to use the new feature names)


#3

Hi, thanks for trying :slight_smile: I looked at the manifest format in the cargo book and it wasn’t clear what was needed so I just made something that compiled.

I can’t reproduce it without the Cargo.lock, because a breaking change in unstable feature names took place very recently and some—but not all—dependencies have updated

Ah, I see. I’ve updated the repo with the lock file in case it is helpful.

plex-0.2.2 can’t build because it does not use the new feature names

Is using the new feature names mandatory or an opt-in thing? I don’t quite understand and search “feature names rust-lang nightly” doesn’t turn up anything useful … could you suggest some place where I can read up on it? Is it something that I should be concerned about going forward if I continue using nightly?


#4

It isn’t so much feature names you have to worry about, but rather just features in general..

My advice is: Unless you are writing throwaway code, avoid nightly-only crates unless they are heavily maintained.. Your safest bet is to look for ones that are very popular (as they couldn’t be popular if they don’t work!)


The key term to look up is unstable features. Unstable features are the opt-in unstable parts of rust only available on nightly (e.g. because they are not fully implemented, or they might change, etc.). There’s a short intro here: https://doc.rust-lang.org/unstable-book/index.html

I’ll reproduce their example here:

#![feature(box_syntax)]

fn main() {
    let five = box 5;
}

In this example, box_syntax is what I referred to as the feature name. (the official term is actually feature flag)

The trouble with using unstable features is that, well… they change! You’ve forfeited the stability guarantees of rust. An argument might be added to a method; a function might get renamed or moved to another module; and, as witnessed here, even the feature flag may be renamed… and any one of these changes create deadly fissures in the nightly-only ecosystem until everybody updates their code.


I see that plex still hasn’t released a new version, so I created an issue: https://github.com/goffrie/plex/issues/29


Thanks for adding the lock file, I’ll look at this again later when I have the chance.


#5

The reason I used nightly was because I wanted to write benchmarks using the #[bench] attribute and macros. Now I’ve got an entirely unrelated problem :slightly_frowning_face:

I just checked and it turns out criterion does work on stable. So I guess I’ll try to switch some dependencies and work on stable only then. Thanks for the suggestion!


#6

I spotted the issue. It’s not your fault; it is due to a line in plex's own Cargo.toml.

It is in fact related to an inconsistency that I’ve noticed earlier in how cargo and rustdoc interact. Basically, if a proc macro crate like plex has this in its Cargo.toml:

# (the syntax advertised in all documentation of proc-macro, and clearly
#  what you are supposed to use)
proc-macro = true

then everything will work fine. If it instead has

# (a form that isn't to my knowledge advertised anywhere, but which is hinted
#  at by some error messages)
crate-type = ["proc-macro"]

then everything will appear to work fine until downstream crates attempt to use rustdoc.


I’ve submitted a PR to plex to fix this, and also opened an issue on rust because cargo doc can actually produce an ICE: