Rollup of 5 pull requests

[Centril]

Successful merges:

• Upgrade rand to 0.7 #63806 (Upgrade rand to 0.7)
• Always emit unresolved import errors and hide unused import lint #64054 (Always emit unresolved import errors and hide unused import lint)
• Bump RLS and Rustfmt submodules to use rustc-ap-* v583 #64279 (Bump RLS and Rustfmt submodules to use rustc-ap-* v583)
• Update LLVM submodule #64317 (Update LLVM submodule)
• Update version of rustc-std-workspace-* crates #64320 (Update version of rustc-std-workspace-* crates)

Failed merges:

r? @ghost

[Centril]

@bors r+ p=5 rollup=never

[bors]

📌 Commit 342722e has been approved by Centril

[bors]

⌛ Testing commit 342722e with merge f06fe4d...

[tmandry]

@Centril Was there a reason not to include #64307 and #64308 in this rollup? If we get those in together with #64279, we should (in theory) be back to a green toolstate.

[Centril]

@tmandry Rolling up 3 PRs that affect the toolstate will almost certainly fail the rollup. I should probably not have rolled up RLS/rustfmt either but they are usually less risky than Clippy.

[mati865]

The problem with Clippy is it depends on various rustc internals. Often it gets broken soon after the fix lands in it's repo but before PR bumping submodule gets even queued.

[bors]

💥 Test timed out

[Centril]

@bors retry

[bors]

⌛ Testing commit 342722e with merge 122fefc...

[tmandry]

@tmandry Rolling up 3 PRs that affect the toolstate will almost certainly fail the rollup. I should probably not have rolled up RLS/rustfmt either but they are usually less risky than Clippy.

Okay, that makes sense.

From the perspective of a project using nightly builds that wants to update to a new version, it typically doesn't make much difference if 1 tool or 4 tools are broken. In theory, any given tool might be used by some person on the team, so it's binary: the only "safe" update is when all tools are green.

Therefore, I have a proposal: if there are changes queued up that, together, would get toolstate all-green again, can they be bundled as a single rollup and given priority? That way,

1. We won't waste CI resources on prioritizing changes that fix individual tools (which are likely to break again soon) when other tools remain broken.
2. When the "stars align" and we have fixes for all tools ready to go, we can prioritize that so master is all-green more of the time (and hopefully more nightlies will be, too.)

I should definitely post this somewhere else, just not sure where :)

[bors]

☀️ Test successful - checks-azure
Approved by: Centril
Pushing 122fefc to master...

[rust-highfive]

📣 Toolstate changed by #64321!

Tested on commit 122fefc.
Direct link to PR: #64321

🎉 rls on windows: build-fail → test-pass (cc @Xanewok, @rust-lang/infra).
🎉 rls on linux: build-fail → test-pass (cc @Xanewok, @rust-lang/infra).
🎉 rustfmt on windows: build-fail → test-pass (cc @topecongiro, @rust-lang/infra).
🎉 rustfmt on linux: build-fail → test-pass (cc @topecongiro, @rust-lang/infra).
💔 rustc-guide on linux: test-pass → test-fail (cc @mark-i-m@spastorino@amanjeev, @rust-lang/infra).