rlib and cdylib crates are marked as 'not a library'

[jyn514]

Looking at https://doc.rust-lang.org/reference/linkage.html, everything except bin is a type of library. I ran into @MaulingMonkey on discord who was confused why his crate wasn't building when he had rlib and cdylib set: https://docs.rs/crate/bugsalot/0.1.5/builds/202497.

[MaulingMonkey]

Seems to have been a regression sometime between rust 1.35 and rust 1.38+ (which also seems to try and include Cargo.lock under the impression that the crate isn't a library) since the manifests didn't change at all besides the version:

https://docs.rs/crate/bugsalot/0.1.4/source/Cargo.toml.orig (published with rust 1.35)
https://docs.rs/crate/bugsalot/0.1.5/source/Cargo.toml.orig (published with rust 1.39. I get similar behavior from cargo package - including the Cargo.lock file - in 1.38, but not in 1.35.)

rlib + cdylib is recommended by wasm-pack docs - I'm not sure how necessary it is for leaf crates like mine though. I do have a workaround: switching from rlib to lib.

(As a side note, if I try to use both rlib and lib simultaniously, instead of replacing the former with the latter, it produces a panic in rust 1.39:)

warning: output filename collision.
The lib target `bugsalot` in package `bugsalot v0.1.6 (C:\local\bugsalot)` has the same output filename as the lib target `bugsalot` in package `bugsalot v0.1.6 (C:\local\bugsalot)`.
Colliding filename is: c:\local\bugsalot\target\x86_64-pc-windows-msvc\debug\deps\libbugsalot.rlib
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
thread 'main' panicked at 'assertion failed: mtimes.insert(output.clone(), mtime).is_none()', src\tools\cargo\src/cargo\core\compiler\fingerprint.rs:795:13
...bogus looking stack backtrace...

[MaulingMonkey]

Okay, apparently I lied about "lib" being a workaround. I tried this for https://docs.rs/crate/bugsalot/0.1.6/ but still no docs.

I also tried publishing with rust 1.35. Again, no docs (https://docs.rs/crate/bugsalot/0.1.7/). While this did exclude Cargo.lock from my local bugsalot-0.1.7.crate, it appears to get re-added by docs.rs: https://docs.rs/crate/bugsalot/0.1.7/source/Cargo.lock

The real workaround is just to drop the crate-types specifier entirely. I've verified it's un-necessary - only the final crate needs it for wasm-pack to be happy, not leaf libs like bugsalot. Proper docs generated this time: https://docs.rs/crate/bugsalot/0.1.8/

[jyn514]

https://docs.rs/crate/bugsalot/0.1.6/source/Cargo.toml may be because #499 hasn't been deployed yet.

[MaulingMonkey]

Looks likely, thanks for looking into this!

[jyn514]

Hmm, so this isn't actually true, you can also have test kinds

[jyn514]

Ok I think the issue is that we're actually looking at kind, which is not the same as crate_types. Here's the output of cargo metadata | jq '.packages | .[].targets | .[] | {crate_types,kind}' -c | sort -u on ripgrep:

{"crate_types":["bin"],"kind":["bench"]}
{"crate_types":["bin"],"kind":["bin"]}
{"crate_types":["bin"],"kind":["custom-build"]}
{"crate_types":["bin"],"kind":["example"]}
{"crate_types":["bin"],"kind":["test"]}
{"crate_types":["lib"],"kind":["lib"]}
{"crate_types":["proc-macro"],"kind":["proc-macro"]}

Notice that the only crate_types listed are bin, lib, and proc-macro, but there's all sorts of kind fields. Here's the same command run on rustc:

{"crate_types":["bin"],"kind":["bench"]}
{"crate_types":["bin"],"kind":["bin"]}
{"crate_types":["bin"],"kind":["custom-build"]}
{"crate_types":["bin"],"kind":["example"]}
{"crate_types":["bin"],"kind":["test"]}
{"crate_types":["dylib"],"kind":["dylib"]}
{"crate_types":["dylib","rlib"],"kind":["dylib","rlib"]}
{"crate_types":["lib"],"kind":["lib"]}
{"crate_types":["proc-macro"],"kind":["proc-macro"]}

I think if we filter the crate_types, not the kind, this should work.

[jyn514]

See also https://doc.rust-lang.org/cargo/commands/cargo-metadata.html

[pietroalbini]

@MaulingMonkey deployed the fix and queued a rebuild for bugsalot 0.1.6! Let me know if there are other crates to rebuild.

[pietroalbini]

@MaulingMonkey it's live! https://docs.rs/bugsalot/0.1.6/bugsalot/

[jyn514]

@pietroalbini can you also rebuild sysinfo 0.10.0?

cc @GuillaumeGomez , #511

[pietroalbini]

Queued sysinfo 0.10.0.

[pravic]

Do we need to republish the affected crates or docs.rs will rebuild them by itself?

[pietroalbini]

@pravic if you tell me the names and versions to rebuild I'll manually queue them.

[pravic]

@pietroalbini https://docs.rs/crate/sciter-rs/0.5.46, https://docs.rs/crate/sciter-rs/0.5.47.

But it would be better to rebuild all affected crates - not everybody has noticed this bug, but those crates are broken anyway.

[pietroalbini]

@pravic rebuilt those crates:

• https://docs.rs/sciter-rs/0.5.46
• https://docs.rs/sciter-rs/0.5.47

Unfortunately it's not trivial to detect which crates were affected automatically and I don't have the time to write an automation to list them.

[jyn514]

@pravic rebuilding automagically is #464