calloop not found

[dhardy]

Crate name

kas-resvg, kas-dylib

Build failure link

https://docs.rs/crate/kas-resvg/0.14.2/builds/1059227
https://docs.rs/crate/kas-dylib/0.14.2/builds/1059229

Additional details

Build fails with:

error: no matching package named calloop found

I can't reproduce locally. Is docs.rs using an outdated crates.io cache?

Weirdly, other crates which should be similarly affected (e.g. kas) are not.

[syphar]

this is an odd failure, and I'm not sure what to make of it.

Is docs.rs using an outdated crates.io cache?
no, we're using up-to-date versions of the registry.

Often these kind of errors relate to the selected features in docs.rs metadata, but I don't see how this can happen here.

@Nemo157 any quick idea?

Otherwise I'll also start digging

[Nemo157]

The issue is almost certainly the kas/winit, kas/wayland "features". We do a separate cargo fetch then cargo rustdoc --offline --features=..., during the fetch cargo pulls down every dependency that might be activated by features of the current crate, but not transitive features of dependencies, so it doesn't know it needs the dependencies for these two features. The fact that cargo allows activating features of dependencies through the command line seems like a bug.

[dhardy]

@Nemo157 thanks for the insight.

As you can see from the linked issue, Cargo explicitly allows activating features of a dependency within the workspace from the command-line, but not otherwise (except some corner-cases which are bugs).

I think a decision should be made here to do one of the following:

1. Emulate usage from the package's workspace by supporting feature specification of dependencies from a workspace.
2. Decide not to support this (deviating from what cargo doc supports on the command line), and hopefully improve the error reporting.

[Nemo157]

I don't know how we would do 1, that would need some support from cargo to allow something like cargo fetch --features kas/winit,kas/wayland to ask it to fetch those transitive optional dependencies.

If rust-lang/cargo#3629 were fixed that should do 2, the cargo rustdoc --features kas/winit step should emit a good error message about not being able to activate that feature of a non-workspace dependency; we could probably reject slashes earlier when parsing the package.metadata.docs.rs.features field, but I don't believe we have a good way to surface errors from that stage.