Cannot compile a crate with a crate-type = ["rlib"] dependency

[danielhenrymantilla]

See danielhenrymantilla/rust-uninit#4

Steps to reproduce the problem

Have a crate with a crate-type = ["rlib"] dependency (that gets used):

cd $(mktemp -d)

cargo init --lib --name foo

cargo new --lib bar && echo 'bar = { path = "bar" }' >> Cargo.toml

cat >>bar/Cargo.toml<<\#\ END
[lib]
crate-type = ["rlib"]
# END

echo 'use ::bar;' >> src/lib.rs

cargo miri test

The last command fails with:

error: extern location for bar does not exist: /private/var/folders/m_/347zzk7j6nz08tt6z3tnd3z00000gn/T/tmp.c7NSx84d/target/x86_64-apple-darwin/debug/deps/libbar-03d28c0dc71f4bad.rmeta
 --> src/lib.rs:8:7
  |
8 | use ::bar;
  |       ^^^

• When I tried to debug this with a -vv flag, the copy-pasted compilation invocation of crate bar yielded no compilation artifacts (mainly, no .rmeta file).

Host context

• As you can see from the error message, this, at least, happens on the x86_64-apple-darwin platform; will try to test this on Linux now Same for x86_64-unknown-linux-gnu.

• cargo -V
  cargo 1.51.0-nightly (783bc43c6 2021-01-20)
  

[RalfJung]

This sounds similar to #1567 (which got fixed) and #1627 (for which we failed to get a reproducible example).

[ghost]

If I remove rlib in

miri/cargo-miri/bin.rs

Lines 599 to 607 in e09dce0

	// rlib and cdylib are just skipped, we cannot interpret them and do not need them
	// for the rest of the build either.
	match get_arg_flag_value("--crate-type").as_deref() {
	Some("rlib") | Some("cdylib") => {
	if verbose {
	eprint!("[cargo-miri rustc] (rlib/cdylib skipped)");
	}
	return;
	}

, this issue disappears.

Actually I don't understand why rlib is there. The documentation says it's the current default of lib:

lib — Generates a library kind preferred by the compiler, currently defaults to rlib.

Maybe that's an oversight from #1577?

[RalfJung]

Maybe? The tricky bit about touching that code is that we have no test for it...
We now have a little workspace for test-cargo-miri, maybe we can have a crate-type = ["cdylib", "rlib"] crate in there? I'll try to craft a test.

[RalfJung]

Okay, with #1708 we have a test. If you can make it so that test still passes, I'm okay. ;)

In a quick local test, you are right -- looks like we can remove rlib from that match.