Multiple matching crates error, if dependency on compiletest is optional

[hannobraun]

I'm trying to use compiletest for a #[no_std] crate. Because the crate contains examples that need to be built for an embedded platform where std is not available (thumbv6m-none-eabi), I needed to make the dependency on compiletest optional and add a Cargo feature for it.

Further details:

• My Cargo.toml (important parts: 1, 2)
• My test file

This works works fine:

$ cargo clean
$ cargo test --features compiletest

This does not work:

$ cargo test
$ cargo test --features compiletest

It results in the following error (excerpt from full build log):

status: exit code: 101
command: "rustc" "tests/compile-fail/swm/assign-function-to-pin-with-unknown-state.rs" "-L" "/tmp" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-C" "prefer-dynamic" "-o" "/tmp/swm/assign-function-to-pin-with-unknown-state.stage-id" "-L" "/home/travis/build/braun-robotics/rust-lpc82x-hal/target/debug/build/cortex-m-rt-e3337e5285e3af86/out" "-L" "/home/travis/build/braun-robotics/rust-lpc82x-hal/target/debug" "-L" "/home/travis/build/braun-robotics/rust-lpc82x-hal/target/debug/deps" "-L" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-L" "/home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib" "-L" "/tmp/swm/assign-function-to-pin-with-unknown-state.stage-id.aux" "-A" "unused"
unexpected errors (from JSON output): [
    Error {
        line_num: 1,
        kind: Some(
            Error
        ),
        msg: "1:1: 1:25: multiple matching crates for `lpc82x_hal` [E0464]"
    },
    Error {
        line_num: 1,
        kind: Some(
            Error
        ),
        msg: "1:1: 1:25: found crate `lpc82x_hal` compiled by an incompatible version of rustc [E0514]"
    }
]

I believe the important part is multiple matching crates. I think I understand what happens here: We have two versions of the crate, one with the feature, one without, and rustc doesn't know which one to use. Is this something that could be fixed in clean_rmeta?