stm32f7xx-hal v0.6.0 docs build failure

[DanHatesNumbers]

Crate name

stm32f7xx-hal

Build failure link

https://docs.rs/crate/stm32f7xx-hal/0.6.0/builds/457266

Additional details

From the build logs, it appears that the build sandbox could not resolve DNS for crates.io despite 2 retries.

[jyn514]

Hmm, this happens because cargo tries to fetch sources for the dependencies when network access is blocked. But those sources should already have been fetched by rustwide before entering the sandbox. I guess cargo might make different decisions for fetching when we pass --target? I wonder if this is related to #1559 somehow.

[Nemo157]

The build is from 2021-11-02, so before the #1559 changes.

[Nemo157]

What's weird is that it's attempting to download stm32-fmc 0.2.4, while the Cargo.lock specifies stm32-fmc 0.2.3, so for some reason the lockfile got invalidated? (but at a point where it should be readonly?)

[Nemo157]

The uploaded Cargo.lock does show 0.2.4 (which answers a question I've long had on whether the uploaded source is actually the crate contents, or docs.rs modifies it during the build).

The build was from before the currently retained logs, so no extra clues there. I have requeued the build to see if it works correctly now or if we can get some more info.

[Nemo157]

Ah, the initial build fails

 error[E0432]: unresolved import `embedded_hal::digital::v2::PinState`
   --> src/gpio.rs:50:9
    |
 50 | pub use embedded_hal::digital::v2::PinState;
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `PinState` in `digital::v2`

then it regenerates the Cargo.lock and tries again (#1490), but it doesn't refetch the newly locked dependencies; and then only uploads the second build log. (EDIT: and testing locally it appears that the second build would have worked if it had the dependency).

[Nemo157]

Has been rebuilt and docs are available.