Rollup of 5 pull requests #64321
Rollup of 5 pull requests #64321
Conversation
This commit updates the version of the `rustc-std-workspace-*` crates in-tree which are used in `[patch]`. This will guarantee that Cargo will select these versions even if minor updates are published to crates.io because otherwise a newer version on crates.io would be preferred which misses the point of `[patch]`!
Upgrade rand to 0.7 Also upgrades `getrandom` to avoid bug encountered by rust-lang#61393 which bumps libc to `0.2.62`.
… r=petrochenkov Always emit unresolved import errors and hide unused import lint Fix rust-lang#63724. r? @petrochenkov
Bump RLS and Rustfmt submodules to use rustc-ap-* v583 Closes rust-lang#64180 Closes rust-lang#64179 r? @topecongiro
Update LLVM submodule Updates the LLVM submodule to current LLVM 9 HEAD. Fixes rust-lang#63918. Fixes rust-lang#63791. r? @alexcrichton
Update version of `rustc-std-workspace-*` crates This commit updates the version of the `rustc-std-workspace-*` crates in-tree which are used in `[patch]`. This will guarantee that Cargo will select these versions even if minor updates are published to crates.io because otherwise a newer version on crates.io would be preferred which misses the point of `[patch]`!
|
@bors r+ p=5 rollup=never |
|
📌 Commit 342722e has been approved by |
bors
added
the
S-waiting-on-bors
Rollup of 5 pull requests Successful merges: - #63806 (Upgrade rand to 0.7) - #64054 (Always emit unresolved import errors and hide unused import lint) - #64279 (Bump RLS and Rustfmt submodules to use rustc-ap-* v583) - #64317 (Update LLVM submodule) - #64320 (Update version of `rustc-std-workspace-*` crates) Failed merges: r? @ghost
|
@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. |
|
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. |
|
💥 Test timed out |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
Rollup of 5 pull requests Successful merges: - #63806 (Upgrade rand to 0.7) - #64054 (Always emit unresolved import errors and hide unused import lint) - #64279 (Bump RLS and Rustfmt submodules to use rustc-ap-* v583) - #64317 (Update LLVM submodule) - #64320 (Update version of `rustc-std-workspace-*` crates) Failed merges: r? @ghost
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,
I should definitely post this somewhere else, just not sure where :) |
|
☀️ Test successful - checks-azure |
|
📣 Toolstate changed by #64321! Tested on commit 122fefc. 🎉 rls on windows: build-fail → test-pass (cc @Xanewok, @rust-lang/infra). |
Tested on commit rust-lang/rust@122fefc. Direct link to PR: <rust-lang/rust#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).
Successful merges:
rustc-std-workspace-*crates #64320 (Update version ofrustc-std-workspace-*crates)Failed merges:
r? @ghost