bevy_mod_picking fails to build

[aevyrie]

Crate name

bevy_mod_picking

Build failure link

https://docs.rs/crate/bevy_mod_picking/0.18.0/builds/1148272

Additional details

I think this latest release added an 11th build target, which is why it is now failing. Running cargo doc --all-features --no-deps --workspace locally generates 11 output files, which I assume is the issue. Unfortunately, the logs are truncated, so I'm just guessing at the issue.

[Nemo157]

That shouldn't be the issue, we only build docs for the lib target. This line makes me think cargo doesn't believe the crate has a lib target for some reason, but skimming the Cargo.toml nothing stands out to me for why that would be:

warning: target filter specified, but no targets matched; this is a no-op

[Nemo157]

Ah wait no, there's more logs that have been stripped because they're too long, they start with:

process didn't exit successfully: `/opt/rustwide/rustup-home/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustdoc --edition=2021 --crate-type lib --crate-name bevy_mod_picking src/lib.rs --target x86_64-unknown-linux-gnu -o /opt/rustwide/target/x86_64-unknown-linux-gnu/doc

and go on for pages and pages of repetitive --extern-html-root-urls (rust-lang/cargo#13543).

That is probably not the cause though, just hiding the ability to see the failure code. I wonder if it is an out of memory error, you could try time -v cargo rustdoc --lib --all-features to see what the memory usage is like.

[aevyrie]

There is a self-referential dev-dependency, maybe it's that? I'll try timing as well.

Command being timed: "cargo rustdoc --lib --all-features"
        User time (seconds): 14.02
        System time (seconds): 3.77
        Percent of CPU this job got: 182%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:09.76
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 576832
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 7908
        Minor (reclaiming a frame) page faults: 1038399
        Voluntary context switches: 2187
        Involuntary context switches: 71758
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 414
        Socket messages received: 618
        Signals delivered: 112
        Page size (bytes): 16384
        Exit status: 0

So, 576 MB if I'm reading this correctly. I'm on macos, so I had to install gtime to get verbose output.

[aevyrie]

I've tried removing the self reference, which doesn't seem to be used, and republished.

[aevyrie]

That did not seem to change anything. https://docs.rs/crate/bevy_mod_picking/0.18.1/builds/1149464

[syphar]

short update: we still don't know the actual error

But we'll wait until cargo is fixed (next nightly or the one after) and try the build again.

Alternatively we see if we can get rust-lang/rustwide#83 released & integrated into docs.rs, and then re-run the build.

[aevyrie]

Let me know if there is anything I can do locally to debug this. Thanks!

[weihanglo]

nightly-2024-03-08 should contain the Cargo fix rust-lang/cargo@ac750a1 Nemo157 mentioned.

[syphar]

thanks for the ping!

I queued a rebuild for bevy_mod_picking 0.18.1 : https://docs.rs/releases/queue

[syphar]

it looks like the build succeeded now:
https://docs.rs/bevy_mod_picking/0.18.1/bevy_mod_picking/

[syphar]

I'm aware we still don't know what the actual build failure was, if it failed becauses of the huge amount of logs? or something else.

[aevyrie]

Thanks!