Rollup of 6 pull requests #120030

matthiaskrgr · 2024-01-16T19:34:03Z

Successful merges:

Deny braced macro invocations in let-else #119062 (Deny braced macro invocations in let-else)
Rework how diagnostic lints are stored. #119922 (Rework how diagnostic lints are stored.)
Move async closure parameters into the resultant closure's future eagerly #119978 (Move async closure parameters into the resultant closure's future eagerly)
Change return type of unstable Waker::noop() from Waker to &Waker. #119984 (Change return type of unstable Waker::noop() from Waker to &Waker.)
Gracefully handle missing typeck information if typeck errored #120020 (Gracefully handle missing typeck information if typeck errored)
don't store const var origins for known vars #120021 (don't store const var origins for known vars)

r? @ghost
@rustbot modify labels: rollup

`Diagnostic::code` has the type `DiagnosticId`, which has `Error` and `Lint` variants. Plus `Diagnostic::is_lint` is a bool, which should be redundant w.r.t. `Diagnostic::code`. Seems simple. Except it's possible for a lint to have an error code, in which case its `code` field is recorded as `Error`, and `is_lint` is required to indicate that it's a lint. This is what happens with `derive(LintDiagnostic)` lints. Which means those lints don't have a lint name or a `has_future_breakage` field because those are stored in the `DiagnosticId::Lint`. It's all a bit messy and confused and seems unintentional. This commit: - removes `DiagnosticId`; - changes `Diagnostic::code` to `Option<String>`, which means both errors and lints can straightforwardly have an error code; - changes `Diagnostic::is_lint` to `Option<IsLint>`, where `IsLint` is a new type containing a lint name and a `has_future_breakage` bool, so all lints can have those, error code or not.

The advantage of this is that it does not need to be assigned to a variable to be used in a `Context` creation, which is the most common thing to want to do with a noop waker. If an owned noop waker is desired, it can be created by cloning, but the reverse is harder. Alternatively, both versions could be provided, like `futures::task::noop_waker()` and `futures::task::noop_waker_ref()`, but that seems to me to be API clutter for a very small benefit, whereas having the `&'static` reference available is a large benefit. Previous discussion on the tracking issue starting here: rust-lang#98286 (comment)

`Waker::noop()` now returns a `&'static Waker` reference, so it can be passed directly to `Context` creation with no temporary lifetime issue.

…=davidtwco,est31 Deny braced macro invocations in let-else Fixes rust-lang#119057 Pending T-lang decision cc `@dtolnay`

… r=oli-obk Rework how diagnostic lints are stored. `Diagnostic::code` has the type `DiagnosticId`, which has `Error` and `Lint` variants. Plus `Diagnostic::is_lint` is a bool, which should be redundant w.r.t. `Diagnostic::code`. Seems simple. Except it's possible for a lint to have an error code, in which case its `code` field is recorded as `Error`, and `is_lint` is required to indicate that it's a lint. This is what happens with `derive(LintDiagnostic)` lints. Which means those lints don't have a lint name or a `has_future_breakage` field because those are stored in the `DiagnosticId::Lint`. It's all a bit messy and confused and seems unintentional. This commit: - removes `DiagnosticId`; - changes `Diagnostic::code` to `Option<String>`, which means both errors and lints can straightforwardly have an error code; - changes `Diagnostic::is_lint` to `Option<IsLint>`, where `IsLint` is a new type containing a lint name and a `has_future_breakage` bool, so all lints can have those, error code or not. r? `@oli-obk`

…ures, r=oli-obk Move async closure parameters into the resultant closure's future eagerly Move async closure parameters into the closure's resultant future eagerly. Before, we used to desugar `async |p1, p2, ..| { body }` as `|p1, p2, ..| { || async { body } }`. Now, we desugar the above like `|p1, p2, ..| { async move { let p1 = p1; let p2 = p2; ... body } }`. This mirrors the same desugaring that `async fn` does with its parameter types, and the compiler literally uses the same code via a shared helper function. This removes the necessity for E0708, since now expressions like `async |x: i32| { x }` will not give you confusing borrow errors. This does *not* fix the case where async closures have self-borrows. This will come with a general implementation of async closures, which is still in the works. r? oli-obk

Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`. The advantage of this is that it does not need to be assigned to a variable to be used in a `Context` creation, which is the most common thing to want to do with a noop waker. It also avoids unnecessarily executing the dynamically dispatched drop function when the noop waker is dropped. If an owned noop waker is desired, it can be created by cloning, but the reverse is harder to do since it requires declaring a constant. Alternatively, both versions could be provided, like `futures::task::noop_waker()` and `futures::task::noop_waker_ref()`, but that seems to me to be API clutter for a very small benefit, whereas having the `&'static` reference available is a large reduction in boilerplate. [Previous discussion on the tracking issue starting here](rust-lang#98286 (comment))

… r=compiler-errors Gracefully handle missing typeck information if typeck errored fixes rust-lang#116893 I created some logs and the typeck of `fn main` is exactly the same, no matter whether the constant's body is what it is, or if it is replaced with `panic!()`. The latter will cause the ICE not to be emitted though. The reason for that is that we abort compilation if *errors* were emitted, but not if *lint errors* were emitted. This took me way too long to debug, and is another reason why I would have liked rust-lang/compiler-team#633

…rrors don't store const var origins for known vars r? types

matthiaskrgr · 2024-01-16T19:34:21Z

@bors r+ rollup=never p=6

bors · 2024-01-16T19:34:24Z

📌 Commit 1a329e4 has been approved by matthiaskrgr

It is now in the queue for this repository.

bors · 2024-01-16T21:35:24Z

⌛ Testing commit 1a329e4 with merge fafb016...

…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#119062 (Deny braced macro invocations in let-else) - rust-lang#119922 (Rework how diagnostic lints are stored.) - rust-lang#119978 (Move async closure parameters into the resultant closure's future eagerly) - rust-lang#119984 (Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`.) - rust-lang#120020 (Gracefully handle missing typeck information if typeck errored) - rust-lang#120021 (don't store const var origins for known vars) r? `@ghost` `@rustbot` modify labels: rollup

rust-log-analyzer · 2024-01-16T21:56:26Z

The job test-various failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)


---- [ui] tests/ui/parser/bad-let-else-statement.rs stdout ----
diff of stderr:

254 LL |             let x = a! () else { return; };
256 
- error: aborting due to 19 previous errors
+ error[E0658]: inline assembly is not stable yet on this architecture
+   --> $DIR/bad-let-else-statement.rs:167:14
+   --> $DIR/bad-let-else-statement.rs:167:14
+    |
+ LL |     let ok = asm!(" nop ") else { return; };
+    |
+    = note: see issue #93335 <https://github.com/rust-lang/rust/issues/93335> for more information
+    = note: see issue #93335 <https://github.com/rust-lang/rust/issues/93335> for more information
+    = help: add `#![feature(asm_experimental_arch)]` to the crate attributes to enable
+    = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
+ error[E0658]: inline assembly is not stable yet on this architecture
+   --> $DIR/bad-let-else-statement.rs:169:15
+    |
+    |
+ LL |     let bad = asm! {" nop "} else { return; };
+    |
+    = note: see issue #93335 <https://github.com/rust-lang/rust/issues/93335> for more information
+    = note: see issue #93335 <https://github.com/rust-lang/rust/issues/93335> for more information
+    = help: add `#![feature(asm_experimental_arch)]` to the crate attributes to enable
+    = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
+ error: aborting due to 21 previous errors
+ 
+ For more information about this error, try `rustc --explain E0658`.
259 
---
status: exit status: 1
command: RUSTC_ICE="0" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/parser/bad-let-else-statement.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "--target=wasm32-unknown-unknown" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "--emit" "metadata" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/parser/bad-let-else-statement" "-A" "unused" "-A" "internal_features" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/wasm32-unknown-unknown/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/parser/bad-let-else-statement/auxiliary"
stdout: none
--- stderr -------------------------------
error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = ({
LL |         1
LL ~     }) else {
   |

error: `for...else` loops are not supported
   |
LL |       let foo = for i in 1..2 {
   |                 --- `else` is attached to this loop
LL |           break;
LL |           break;
LL |       } else {
   |  _______^
LL | |         //~^ ERROR `for...else` loops are not supported
LL | |     };
   | |_____^
   |
   |
   = note: consider moving this `else` clause to a separate `if` statement and use a `bool` variable to control if it should run

error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
---
LL |         0
LL ~     }) else {
   |

error: `loop...else` loops are not supported
   |
LL |       let foo = loop {
   |                 ---- `else` is attached to this loop
LL |           break;
LL |           break;
LL |       } else {
   |  _______^
LL | |         //~^ ERROR loop...else` loops are not supported
LL | |     };
   | |_____^
   |
   |
   = note: consider moving this `else` clause to a separate `if` statement and use a `bool` variable to control if it should run

error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = (match true {
LL |         true => 1,
LL |         false => 0
LL ~     }) else {


error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = (X {
LL |         a: 1
LL ~     }) else {


error: `while...else` loops are not supported
   |
LL |       let foo = while false {
   |                 ----- `else` is attached to this loop
LL |           break;
LL |           break;
LL |       } else {
   |  _______^
LL | |         //~^ ERROR `while...else` loops are not supported
LL | |     };
   | |_____^
   |
   |
   = note: consider moving this `else` clause to a separate `if` statement and use a `bool` variable to control if it should run

error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = (const {
LL |         1
LL ~     }) else {
   |

error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = &({
LL |         1
LL ~     }) else {
   |

error: right curly brace `}` before `else` in a `let...else` statement not allowed
Build completed unsuccessfully in 0:16:31
   |
LL |     } else {
   |     ^
   |     ^
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = bar = ({
LL ~     }) else {
   |


error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = 1 + ({
LL ~     }) else {
   |


error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = 1..({
LL ~     }) else {
   |


error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = return ({
LL ~     }) else {
   |


error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = -({
LL ~     }) else {
   |


error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = do yeet ({
LL ~     }) else {
   |


error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = become ({
LL ~     }) else {
   |


error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
LL |     } else {
   |     ^
   |
   |
help: wrap the expression in parentheses
   |
LL ~     let foo = |x: i32| ({
LL ~     }) else {
   |


error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
   |
LL |     let bad = asm! {" nop "} else { return; };
   |
help: use parentheses instead of braces for this macro
   |
   |
LL |     let bad = asm! (" nop ") else { return; };


error: right curly brace `}` before `else` in a `let...else` statement not allowed
   |
   |
LL |             let x = a! {} else { return; };
...
...
LL |     b!(1); b!(2);
   |
   = note: this error originates in the macro `b` (in Nightly builds, run with -Z macro-backtrace for more info)
help: use parentheses instead of braces for this macro
   |
   |
LL |             let x = a! () else { return; };

error[E0658]: inline assembly is not stable yet on this architecture
##[error]  --> /checkout/tests/ui/parser/bad-let-else-statement.rs:167:14
   |
   |
LL |     let ok = asm!(" nop ") else { return; };
   |
   = note: see issue #93335 <https://github.com/rust-lang/rust/issues/93335> for more information
   = note: see issue #93335 <https://github.com/rust-lang/rust/issues/93335> for more information
   = help: add `#![feature(asm_experimental_arch)]` to the crate attributes to enable
   = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
error[E0658]: inline assembly is not stable yet on this architecture
##[error]  --> /checkout/tests/ui/parser/bad-let-else-statement.rs:169:15
   |
   |
LL |     let bad = asm! {" nop "} else { return; };
   |
   = note: see issue #93335 <https://github.com/rust-lang/rust/issues/93335> for more information
   = note: see issue #93335 <https://github.com/rust-lang/rust/issues/93335> for more information
   = help: add `#![feature(asm_experimental_arch)]` to the crate attributes to enable
   = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
error: aborting due to 21 previous errors

For more information about this error, try `rustc --explain E0658`.
------------------------------------------

bors · 2024-01-16T21:57:03Z

💔 Test failed - checks-actions

nnethercote and others added 20 commits January 14, 2024 09:46

Reformat struct_span_code_err!.

2de99ec

Remove unnecessary lets and borrowing from Waker::noop() usage.

219b00d

`Waker::noop()` now returns a `&'static Waker` reference, so it can be passed directly to `Context` creation with no temporary lifetime issue.

Don't create the array type twice

9a8f117

Document why Waker::noop()'s implementation is the shape it is.

7052188

don't store const var origins for known vars

290651b

Skip dead code checks on items that failed typeck

3599c18

Introduce helper that deals with moving async args into the coroutine

8bb1eae

Deny braced macro invocations in let-else

f56a4c0

Suggest wrapping mac args in parens rather than the whole expression

fd02369

Async closures will move params into the future always

f1ee076

Fix async closure call suggestion

f4e35c6

Deal with additional wrapping of async closure body in clippy

04a5ee6

Rollup merge of rust-lang#119062 - compiler-errors:asm-in-let-else, r…

98a789c

…=davidtwco,est31 Deny braced macro invocations in let-else Fixes rust-lang#119057 Pending T-lang decision cc `@dtolnay`

Rollup merge of rust-lang#120021 - lcnr:const-var-value, r=compiler-e…

1a329e4

…rrors don't store const var origins for known vars r? types

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 Jan 16, 2024

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 Jan 16, 2024

matthiaskrgr mentioned this pull request Jan 16, 2024

Deny braced macro invocations in let-else #119062

Merged

matthiaskrgr closed this Jan 16, 2024

matthiaskrgr deleted the rollup-38h12rs branch March 16, 2024 18:18

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rollup of 6 pull requests #120030

Rollup of 6 pull requests #120030

matthiaskrgr commented Jan 16, 2024

matthiaskrgr commented Jan 16, 2024

bors commented Jan 16, 2024

bors commented Jan 16, 2024

rust-log-analyzer commented Jan 16, 2024

bors commented Jan 16, 2024

Rollup of 6 pull requests #120030

Rollup of 6 pull requests #120030

Conversation

matthiaskrgr commented Jan 16, 2024

matthiaskrgr commented Jan 16, 2024

bors commented Jan 16, 2024

bors commented Jan 16, 2024

rust-log-analyzer commented Jan 16, 2024

bors commented Jan 16, 2024