rustbuild: smarter git submodule-ing

[japaric]

With this commit, if one bootstraps rust against system llvm then the
src/llvm submodule is not updated/checked-out. This saves considerable
network bandwith when starting from a fresh clone of rust-lang/rust as
the llvm submodule is never cloned.

cc #30107

r? @alexcrichton
cc @petevine

We could also avoid updating the jemalloc submodule if --disable-jemalloc is used. It just hasn't been implemented. Done

This probably doesn't handle "recursive" submodules correctly but I think we don't have any of those right now.

I'm still testing a bootstrap but already confirmed that the llvm submodule doesn't get updated when --llvm-root is passed to configure.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[alexcrichton]

@bors: r+ 5683bf9

Thanks!

[japaric]

Fixed tidy error

@bors r=alexcrichton

[bors]

📌 Commit 4b5007a has been approved by alexcrichton

[bors]

⌛ Testing commit 4b5007a with merge 86dde9b...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-no-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-no-mir, auto-win-msvc-64-opt-rustbuild
Approved by: alexcrichton
Pushing 86dde9b to master...

[TimNN]

I think this PR lead to the recent buildbot failures:

Original Failure (I believe):

    Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
Synchronizing submodule url for 'src/compiler-rt'
Synchronizing submodule url for 'src/jemalloc'
Synchronizing submodule url for 'src/liblibc'
Synchronizing submodule url for 'src/llvm'
Synchronizing submodule url for 'src/rt/hoedown'
Synchronizing submodule url for 'src/rust-installer'
HEAD is now at 8598065 Rust: fix MSVC-built lib pulling in other lib files
HEAD is now at e058ca6 Change how the default zone is found
HEAD is now at 5066b7d Merge pull request #341 from japaric/arm-musl
      0 [main] git 2760 cygwin_exception::open_stackdumpfile: Dumping stack trace to git.exe.stackdump


command did not execute successfully: "git" "-C" "src/llvm" "reset" "--hard"
expected success, got: exit code: 35584


Makefile:23: recipe for target 'all' failed
>> rustjob: found 0 remaining processes
make: *** [all] Error 1

(And then cascading failures because git was killed without cleaning up lock files, I believe).

[alexcrichton]

Thanks for the investigation @TimNN! I do believe that's the original failure, and I do believe that it's causing the cascading failures. Now I have no idea what that failure means unfortunately... I don't think this PR is itself directly responsible for that but I could be wrong...

I think I'm going to clean out all the bots and retry everything. If this happens again we can revert but for now I'm gonna assume that this was a very unfortunately timed "standard random segfault on Windows"