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

async blocks in a const-context error on nightly, but not on stable #77361

Closed
DutchGhost opened this issue Sep 30, 2020 · 10 comments
Closed

async blocks in a const-context error on nightly, but not on stable #77361

DutchGhost opened this issue Sep 30, 2020 · 10 comments
Assignees
Labels
A-async-await Area: Async & Await A-const-eval Area: constant evaluation (mir interpretation) A-stability Area: issues related to #[stable] and #[unstable] attributes themselves. AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. P-medium Medium priority requires-nightly This issue requires a nightly compiler in some way.

Comments

@DutchGhost
Copy link
Contributor

DutchGhost commented Sep 30, 2020

The following code compiles on stable, but not on nightly. I know this is realy bogus code, and I'm not sure it should be rejected:

fn regress() -> [(); { core::mem::ManuallyDrop::new(async { 0 }); 4 }] {
    todo!()
}

On nightly, the error message is:

error: `from_generator` is not yet stable as a const fn
 --> src/lib.rs:2:60
  |
2 | fn regress() -> [(); { core::mem::ManuallyDrop::new(async { 0 }); 4 }] {
  |                                                            ^^^^^^^^^
  |
  = help: add `#![feature(gen_future)]` to the crate attributes to enable

error: aborting due to previous error

error: could not compile `playground`

To learn more, run the command again with --verbose.
@LeSeulArtichaut LeSeulArtichaut added the I-prioritize Indicates that prioritization has been requested for this issue label Sep 30, 2020
@lcnr
Copy link
Contributor

lcnr commented Sep 30, 2020

cc @ecstatic-morse in case this is related to what you were doing recently

@tesuji
Copy link
Contributor

tesuji commented Sep 30, 2020

searched nightlies: from nightly-2020-08-20 to nightly-2020-09-30
regressed nightly: nightly-2020-09-24
searched commits: from 0da5800 to 8b40853
regressed commit: f6d5920

bisected with cargo-bisect-rustc v0.5.2

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc 2020-08-20 --end 2020-09-30 --preserve --regress=error --without-cargo 

That's #76850

@LeSeulArtichaut LeSeulArtichaut added the A-const-eval Area: constant evaluation (mir interpretation) label Sep 30, 2020
@jonas-schievink jonas-schievink added A-stability Area: issues related to #[stable] and #[unstable] attributes themselves. C-bug Category: This is a bug. regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Sep 30, 2020
@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented Sep 30, 2020

cc @rust-lang/wg-const-eval This code was allowed erroneously; async-await has not been stabilized in a const-context. I believe we have exceptions to the backwards compatibility rules for cases like this? Actually doing anything with the async block (.await, dropping it) will cause an error during const-checking, so this is useless as far as I know.

This also works in a regular const initializer:

const _: i32 = { core::mem::ManuallyDrop::new(async { 0 }); 4 };

@camelid
Copy link
Member

camelid commented Sep 30, 2020

Hmm, the span in the error shown above seems wrong:

error: `from_generator` is not yet stable as a const fn
 --> src/lib.rs:2:60
  |
2 | fn regress() -> [(); { core::mem::ManuallyDrop::new(async { 0 }); 4 }] {
  |                                                            ^^^^^^^^^
  |
  = help: add `#![feature(gen_future)]` to the crate attributes to enable

It's pointing at the section from the space before the 0 to the space after the 4? But the error from putting it into a fresh playground looks correct:

error: `from_generator` is not yet stable as a const fn
 --> src/lib.rs:1:53
  |
1 | fn regress() -> [(); { core::mem::ManuallyDrop::new(async { 0 }); 4 }] {
  |                                                     ^^^^^^^^^^^
  |
  = help: add `#![feature(gen_future)]` to the crate attributes to enable

@DutchGhost is that how the error appeared to you when you ran into it?

@camelid camelid added A-async-await Area: Async & Await P-medium Medium priority labels Sep 30, 2020
@camelid
Copy link
Member

camelid commented Sep 30, 2020

Temporarily assigning P-medium per the prioritization working group discussion.

@camelid camelid removed the I-prioritize Indicates that prioritization has been requested for this issue label Sep 30, 2020
@oli-obk
Copy link
Contributor

oli-obk commented Sep 30, 2020

Yea this was never intended to get stabilized and since it's only possible in code that doesn't actually do anything, this is unlikely to occur in practice. I don't see a reasonable way to allow this. Note the same effect is possible with std::mem::forget.

@camelid
Copy link
Member

camelid commented Sep 30, 2020

So should we remove regression-from-stable-to-nightly? It sounds like it's not a regression; it's a bug fix.

@RalfJung
Copy link
Member

RalfJung commented Sep 30, 2020

I agree that this falls under "accidental stabilization", and is not a regression.

This also works in a regular const initializer:

Still works, or used to work? If it still works that arguably is a bug,

@camelid camelid added requires-nightly This issue requires a nightly compiler in some way. and removed regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Sep 30, 2020
@ecstatic-morse ecstatic-morse self-assigned this Sep 30, 2020
@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented Sep 30, 2020

The second. You can try it in the playground.

I'm assigning myself to give a better error message in these cases, but this will remain an error going forward.

@ecstatic-morse ecstatic-morse changed the title Compilation succeeds on stable, but not on nightly async blocks in a const-context error on nightly, but not on stable Sep 30, 2020
@LeSeulArtichaut LeSeulArtichaut removed the C-bug Category: This is a bug. label Sep 30, 2020
ecstatic-morse added a commit to ecstatic-morse/rust that referenced this issue Oct 1, 2020
ecstatic-morse added a commit to ecstatic-morse/rust that referenced this issue Oct 1, 2020
jonas-schievink added a commit to jonas-schievink/rust that referenced this issue Oct 2, 2020
…-block, r=oli-obk

Better error message for `async` blocks in a const-context

Improves the error message for the case in rust-lang#77361.

r? @oli-obk
@tmandry tmandry added the AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. label Oct 6, 2020
@DutchGhost
Copy link
Contributor Author

DutchGhost commented Oct 14, 2020

Since the PR improving the error message for cases like this has been merged, this issue can be closed?

@oli-obk oli-obk closed this as completed Oct 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-async-await Area: Async & Await A-const-eval Area: constant evaluation (mir interpretation) A-stability Area: issues related to #[stable] and #[unstable] attributes themselves. AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. P-medium Medium priority requires-nightly This issue requires a nightly compiler in some way.
Projects
None yet
Development

No branches or pull requests

10 participants