Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 8 pull requests #98505

Closed
wants to merge 28 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

joboet and others added 28 commits May 18, 2022 12:18
Co-authored-by: Tomoaki Kawada <kawada@kmckk.co.jp>
When a binding is declared without a value, borrowck verifies that all
codepaths have *one* assignment to them to initialize them fully. If
there are any cases where a condition can be met that leaves the binding
uninitialized or we attempt to initialize a field of an unitialized
binding, we emit E0381.

We now look at all the statements that initialize the binding, and use
them to explore branching code paths that *don't* and point at them. If
we find *no* potential places where an assignment to the binding might
be missing, we display the spans of all the existing initializers to
provide some context.
Of primary interest, this merges
rust-lang/rls@ece09b8 into rust-lang/rust,
which brings in the changes that fix RLS tests broken by rust-lang#97853. rust-lang#97853 already
introduced that commit's changes (under
27f4044df03d15c7c38a483c3e4635cf4f51807d) but without putting those changes on
rust-lang/rls as a branch, so we ended up with an orphan commit that caused
trouble when updating submodules in rust-lang/rust.

This commit, once merged into rust-lang/rust, should continue to let RLS tests
to pass on rust-lang/rust's side and move us back into a healthy state where tip
of the submodule points to a valid master commit in the rust-lang/rls
repository.
std: use an event-flag-based thread parker on SOLID

`Mutex` and `Condvar` are being replaced by more efficient implementations, which need thread parking themselves (see rust-lang#93740). Therefore, the generic `Parker` needs to be replaced on all platforms where the new lock implementation will be used, which, after rust-lang#96393, are SOLID, SGX and Hermit (more PRs coming soon).

SOLID, conforming to the [μITRON specification](http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf), has event flags, which are a thread parking primitive very similar to `Parker`. However, they do not make any atomic ordering guarantees (even though those can probably be assumed) and necessitate a system call even when the thread token is already available. Hence, this `Parker`, like the Windows parker, uses an extra atomic state variable.

I future-proofed the code by wrapping the event flag in a `WaitFlag` structure, as both SGX and Hermit can share the Parker implementation, they just have slightly different primitives (SGX uses signals and Hermit has a thread blocking API (which is unfortunately [broken](hermit-os/kernel#442), I think).

````@kawadakk```` I assume you are the target maintainer? Could you test this for me?
…ompiler-errors

[rustc_parse] Forbid `let`s in certain places

Currently only forbids in locals to resolve rust-lang#94927 (comment) but feel free to point any other places.
…notriddle

Transform help popup into a pocket menu

Just like we moved the settings menu into a "pocket menu", it's doing the same to the help popup.

You can test it [here](https://rustdoc.crud.net/imperio/help-pocket-menu/doc/foo/index.html) and here is a screenshot:

![Screenshot from 2022-06-20 20-58-29](https://user-images.githubusercontent.com/3050060/174663718-538e9d11-3bf9-48b2-8909-f9bfe75af135.png)

r? `````@jsha`````
 On partial uninit error point at where we need init

When a binding is declared without a value, borrowck verifies that all
codepaths have *one* assignment to them to initialize them fully. If
there are any cases where a condition can be met that leaves the binding
uninitialized or we attempt to initialize a field of an uninitialized
binding, we emit E0381.

We now look at all the statements that initialize the binding, and use
them to explore branching code paths that *don't* and point at them. If
we find *no* potential places where an assignment to the binding might
be missing, we display the spans of all the existing initializers to
provide some context.

Fix rust-lang#97956.
…ing, r=oli-obk

Fix printing `impl trait` under binders

Before, we would render `impl for<'a> Trait<'a>` like `impl Trait<for<'a> 'a>`, lol.
x.py: Support systems with only `python3` not `python`

Fixes rust-lang#71818 without the pitfalls so far described in previous attempts.
…lbini

Bump RLS to latest master on rust-lang/rls

Of primary interest, this merges
rust-lang/rls@ece09b8 into rust-lang/rust,
which brings in the changes that fix RLS tests broken by rust-lang#97853. rust-lang#97853 already
introduced that commit's changes (under
rust-lang/rls@27f4044) but without putting those changes on
rust-lang/rls as a branch, so we ended up with an orphan commit that caused
trouble when updating submodules in rust-lang/rust.

This commit, once merged into rust-lang/rust, should continue to let RLS tests
to pass on rust-lang/rust's side and move us back into a healthy state where tip
of the submodule points to a valid master commit in the rust-lang/rls
repository.

cc rust-lang#98451, but not marking as fixed as I believe we need to add verification to prevent future oversights.
…abort, r=Dylan-DPC

Fix backtrace UI test when panic=abort is used

The function `contains_verbose_expected` is only used when the panic strategy is not abort, so it caused a warning when it was abort, which made the UI test failed on stderr comparison.
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 25, 2022
@rustbot rustbot added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jun 25, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=8

@bors
Copy link
Contributor

bors commented Jun 25, 2022

📌 Commit 2761d5f has been approved by matthiaskrgr

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 25, 2022
@bors
Copy link
Contributor

bors commented Jun 25, 2022

⌛ Testing commit 2761d5f with merge 16b3e326cd0a82e34dcceecac65c9dec5d31a83c...

@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] rustc_middle test:false 229.036
[RUSTC-TIMING] rustc_mir_transform test:false 105.139
[RUSTC-TIMING] rustc_borrowck test:false 119.139
[RUSTC-TIMING] rustc_typeck test:false 127.417
##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.

@bors
Copy link
Contributor

bors commented Jun 26, 2022

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 26, 2022
@compiler-errors
Copy link
Member

@bors retry "the runner has received a shutdown signal" hopefully spurious?

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 26, 2022
@bors
Copy link
Contributor

bors commented Jun 26, 2022

⌛ Testing commit 2761d5f with merge 09ef74fee7fc6620bd437158371e2e9bc647e8ab...

@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
test [ui] src/test/ui/rfc-2497-if-let-chains/ast-pretty-check.rs ... ok
test [ui] src/test/ui/rfc-2497-if-let-chains/chains-without-let.rs ... ok
test [ui] src/test/ui/rfc-2497-if-let-chains/feature-gate.rs ... ok
test [ui] src/test/ui/rfc-2294-if-let-guard/run-pass.rs ... ok
test [ui] src/test/ui/rfc-2497-if-let-chains/invalid-let-in-a-valid-let-context.rs ... ok
test [ui] src/test/ui/rfc-2091-track-caller/tracked-closure.rs ... ok
test [ui] src/test/ui/rfc-2497-if-let-chains/irrefutable-lets.rs#allowed ... ok
test [ui] src/test/ui/rfc-2497-if-let-chains/issue-90722.rs ... ok
test [ui] src/test/ui/rfc-2497-if-let-chains/issue-93150.rs ... ok
---

---- [ui] src/test/ui/asm/aarch64/type-check-2-2.rs stdout ----
diff of stderr:

- error[E0381]: use of possibly-uninitialized variable: `x`
+ error[E0381]: used binding `x` isn't initialized
3    |
+ LL |         let x: u64;
Some tests failed in compiletest suite=ui mode=ui host=aarch64-unknown-linux-gnu target=aarch64-unknown-linux-gnu
Some tests failed in compiletest suite=ui mode=ui host=aarch64-unknown-linux-gnu target=aarch64-unknown-linux-gnu
+    |             - binding declared here but left uninitialized
4 LL |         asm!("{}", in(reg) x);
-    |                            ^ use of possibly-uninitialized `x`
+    |                            ^ `x` used here but it isn't initialized
6 
- error[E0381]: use of possibly-uninitialized variable: `y`
+ error[E0381]: used binding `y` isn't initialized
9    |
+ LL |         let mut y: u64;
+ LL |         let mut y: u64;
+    |             ----- binding declared here but left uninitialized
10 LL |         asm!("{}", inout(reg) y);
-    |         ^^^^^^^^^^^^^^^^^^^^^^^^ use of possibly-uninitialized `y`
+    |         ^^^^^^^^^^^^^^^^^^^^^^^^ `y` used here but it isn't initialized
12 
13 error[E0596]: cannot borrow `v` as mutable, as it is not declared as mutable


The actual stderr differed from the expected stderr.
The actual stderr differed from the expected stderr.
Actual stderr saved to /checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/asm/aarch64/type-check-2-2/type-check-2-2.stderr
To only update this specific test, also pass `--test-args asm/aarch64/type-check-2-2.rs`

error: 1 errors occurred comparing output.
status: exit status: 1
status: exit status: 1
command: "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/asm/aarch64/type-check-2-2.rs" "-Zthreads=1" "--target=aarch64-unknown-linux-gnu" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Cstrip=debuginfo" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/asm/aarch64/type-check-2-2" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/aarch64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/asm/aarch64/type-check-2-2/auxiliary"
stdout: none
--- stderr -------------------------------
error[E0381]: used binding `x` isn't initialized
   |
LL |         let x: u64;
LL |         let x: u64;
   |             - binding declared here but left uninitialized
LL |         asm!("{}", in(reg) x);
   |                            ^ `x` used here but it isn't initialized

error[E0381]: used binding `y` isn't initialized
   |
LL |         let mut y: u64;
LL |         let mut y: u64;
   |             ----- binding declared here but left uninitialized
LL |         asm!("{}", inout(reg) y);
   |         ^^^^^^^^^^^^^^^^^^^^^^^^ `y` used here but it isn't initialized

error[E0596]: cannot borrow `v` as mutable, as it is not declared as mutable
   |
   |
LL |         let v: Vec<u64> = vec![0, 1, 2];
   |             - help: consider changing this to be mutable: `mut v`
LL |         asm!("{}", in(reg) v[0]);
LL |         asm!("{}", out(reg) v[0]);
   |                             ^ cannot borrow as mutable

error[E0596]: cannot borrow `v` as mutable, as it is not declared as mutable
   |
   |
LL |         let v: Vec<u64> = vec![0, 1, 2];
   |             - help: consider changing this to be mutable: `mut v`
...
LL |         asm!("{}", inout(reg) v[0]);
   |                               ^ cannot borrow as mutable
error: aborting due to 4 previous errors

Some errors have detailed explanations: E0381, E0596.
For more information about an error, try `rustc --explain E0381`.

@bors
Copy link
Contributor

bors commented Jun 26, 2022

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 26, 2022
@JohnTitor
Copy link
Member

Failed by #98360, closing.

@JohnTitor JohnTitor closed this Jun 26, 2022
@matthiaskrgr matthiaskrgr deleted the rollup-zq9kk8b branch July 30, 2022 10:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.