thread 'main' panicked at src/bootstrap/src/utils/helpers.rs:441:5

[psumbera]

Build on Solaris fails with:

Submodule path 'src/doc/rust-by-example': checked out '093397535b48ae13ec76bc526b7e6eb8c096a85c'
thread 'main' panicked at src/bootstrap/src/utils/helpers.rs:441:5:
std::fs::read_dir(dir) failed with No such file or directory (os error 2)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:03:34

MIght be related to #134967 ?!

[jieyouxu]

@psumbera does it repro if you git submodule deinit -f -all then try running the doc step again? Sometimes submodule checkouts can become funky, and the submodule can somehow become in a limbo state.

[onur-ozkan]

I assume you don't have some paths from .gitmodules file, which is not usual for building from source.

[psumbera]

I normally do just:
git clone https://github.com/rust-lang/rust.git /builds/rust-lang
Now when I do also:
cd /builds/rust-lang && git submodule update --init --recursive
it seems to build just fine...

Is there documentation how to properly clone Rust for build? So far my way was working...

[jieyouxu]

You should just be able to git clone without having to manually init submodules. ./x.py should automatically manage it for you, but sometimes submodule states can somehow become corrupted...

[jieyouxu]

FTR, I tried a fresh clone, and I wasn't able to repro (e.g. just ./x doc src/doc/rust-by-example, without manually init-ing submodules). I suspect you just got very unlucky with the submodule checkout. I'm going to close this as inactionable because we can't repro, but please re-open if this is still problematic for you.

[psumbera]

Ok, it may be difference too. For historical reasons I'm still using:
./configure --default-linker=gcc --release-channel=$RELEASE --enable-extended --tools="cargo,rustfmt"
gmake dist

[joshtriplett]

I'm encountering this issue as well, in a fresh Rust clone. Happy to try any diagnostic steps that might help.

I wrote #135094 to make the error message more specific.

With that, I see:

std::fs::read_dir(dir) failed with No such file or directory (os error 2) ("/home/josh/src/rust2/src/tools/cargo/src/doc")

[joshtriplett]

If I manually git submodule init src/tools/cargo and git submodule update, and then run ./x test again, it no longer hits this error.

[jieyouxu]

That is weird...

[joshtriplett]

Any chance the mechanism added for #134967 is failing to handle the Cargo repository?

If that isn't straightforward to debug, could we revert that until it's no longer causing this issue?

[jieyouxu]

It's possible. @onur-ozkan do you know if we could somehow be not checking out the doc submodules I wonder?

[jieyouxu]

Oh wait I see why, the submodule path can diverge with the primary path provided in doc step, I missed that during review. I'll send a PR after I cromch dinner.

-    CargoBook, "src/tools/cargo/src/doc", "cargo", &[], submodule = "src/tools/cargo";
+    CargoBook, "src/tools/cargo/src/doc", "cargo", &[];

The filter logic tries to query src/tools/cargo/src/doc instead of src/tools/cargo.

[jieyouxu]

I'm encountering this issue as well, in a fresh Rust clone. Happy to try any diagnostic steps that might help.

I wrote #135094 to make the error message more specific.

With that, I see:

std::fs::read_dir(dir) failed with No such file or directory (os error 2) ("/home/josh/src/rust2/src/tools/cargo/src/doc")

@joshtriplett I have a candidate fix, but could you spell out which exact invocation you used on the fresh checkout?

[jieyouxu]

Actually nevermind I can on master:

[19:11] Joe:rust (fresh) | ./x doc src/tools/cargo/src/doc
Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.01s
Updating submodule library/backtrace
Submodule 'library/backtrace' (https://github.com/rust-lang/backtrace-rs.git) registered for path 'library/backtrace'
Submodule path 'library/backtrace': checked out '4d7906bb24ae91ee6587127020d360f5298f9e7e'
Updating submodule library/stdarch
Submodule 'library/stdarch' (https://github.com/rust-lang/stdarch.git) registered for path 'library/stdarch'
Submodule path 'library/stdarch': checked out '684de0d6fef708cae08214fef9643dd9ec7296e1'
thread 'main' panicked at src/bootstrap/src/utils/helpers.rs:441:5:
std::fs::read_dir(dir) failed with No such file or directory (os error 2)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:00

[jieyouxu]

Any chance the mechanism added for #134967 is failing to handle the Cargo repository?

If that isn't straightforward to debug, could we revert that until it's no longer causing this issue?

I have a candidate fix in #135096.