-
Notifications
You must be signed in to change notification settings - Fork 13.3k
async/await: “the requirement for<'r> 'r : 'static
is not satisfied” with 'static
across await point
#53548
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
This makes the code similar to the handling of `ty::Ref` in `src/librustc/ty/wf.rs`, except checking for non-escaping-regions somewhere down the call chain instead of at the root. Fixes rust-lang#53548
Some work has started on #53736 ; the information there will likely be helpful to someone trying to fix this. |
I think I've hit this with a generator-only code. #![feature(generators)]
use std::cell::RefCell;
use std::rc::Rc;
trait Trait: 'static {}
struct Store<C> {
inner: Rc<RefCell<Option<C>>>,
}
#[test]
fn test_compose() {
Box::new(static move || {
let store = Store::<Box<dyn Trait>> {
inner: Default::default(),
};
yield ();
});
} |
I'm marking this issue as blocking the async-await stabilization -- if nothing else, we need to investigate it and figure out what is going on. |
I did some more digging into this problem. This code will actually ICE if using a version of rustc built with debug assertions. Moreover, the follow example code -- which doesn't use generators at all -- will ICE in the same way: use std::cell::RefCell;
use std::rc::Rc;
trait Trait: 'static {}
struct Store<C> {
inner: Rc<RefCell<Option<C>>>,
}
fn main() {
let store = Store::<Box<for<'a> fn(&(dyn Trait + 'a))>> {
inner: Default::default(),
};
} the problem here ultimately has to do with the way that the WF code works. I left some obscure notes on Zulip, but the bottom line is something like this:
So in this particular case we wind up with a type It's kind of hard to stumble across this ICE normally, because Pursuant with the existing lazy strategy, I think the right fix is just for the wf code to ignore the |
…bound, r=pnkfelix ignore higher-ranked object bound conditions created by WF In the `issue-53548` test added in this PR, the `Box<dyn Trait>` type is expanded to `Box<dyn Trait + 'static>`, but the generator "witness" that results is `for<'r> { Box<dyn Trait + 'r> }`. The WF code was encountering an ICE (when debug-assertions were enabled) and an unexpected compilation error (without debug-asserions) when trying to process this `'r` region bound. In particular, to be WF, the region bound must meet the requirements of the trait, and hence we got `for<'r> { 'r: 'static }`. This would ICE because the `Binder` constructor we were using was assering that no higher-ranked regions were involved (because the WF code is supposed to skip those). The error (if debug-asserions were disabled) came because we obviously cannot prove that `'r: 'static` for any region `'r`. Pursuant with our "lazy WF" strategy for higher-ranked regions, the fix is not to require that `for<'r> { 'r: 'static }` holds (this is also analogous to what we would do for higher-ranked regions appearing within the trait in other positions). Fixes rust-lang#53548 r? @pnkfelix
Great, thank you! I can confirm that on latest nightly the issue is no longer there :D |
(continuation of rust-lang/futures-rs#1199 as it looks like a compiler bug after all, important points repeated here)
Problem
There appear to be an issue in handling traits that have a parent
'static
bound boxed through an await point: the following example fails to compile withthe requirement
for<'r> 'r : 'staticis not satisfied
(note: I'm using generators for simplicity of reproduction, see below for a futures-only example)(playground link)
However, when removing the
'static
bound onTrait
, it appears to compile correctly, even though theBox
itself still has the+ 'static
bound.(playground link)
Futures-only version
The error originated in code that looked like:
The
Any
being here the trait that has the'static
bound. This was tested withfutures-rs
at commit rust-lang/futures-rs@c02ec75 and nightly 2018-08-14.No generator-only version
I couldn't manage to get a generator-only version to fail: this compiles.
(playground link)
Potentially related issue
This is potentially related to #53259, as the same
for<'r>
appears there?The text was updated successfully, but these errors were encountered: