Change:
<ins> // Regression test for #53548. The `Box<dyn Trait>` type below 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). // // compile-pass #![feature(generators)] use std::cell::RefCell; use std::rc::Rc; trait Trait: 'static {} struct Store<C> { inner: Rc<RefCell<Option<C>>>, } fn main() { Box::new(static move || { let store = Store::<Box<dyn Trait>> { inner: Default::default(), }; yield (); }); } </ins>

Discussion:
(continuation of as it looks like a compiler bug after all, important points repeated here) There appear to be an issue in handling traits that have a parent bound boxed through an await point: the following example fails to compile with for<'r'r : 'static (note: I'm using generators for simplicity of reproduction, see below for a futures-only example) However, when removing the bound on , it appears to compile correctly, even though the itself still has the bound. The error originated in code that looked like: The being here the trait that has the bound. This was tested with at commit and nightly 2018-08-14. I couldn't manage to get a generator-only version to fail: this compiles. This is potentially related to , as the same appears there?
Some work has started on ; the information there will likely be helpful to someone trying to fix this.
I think I've hit this with a generator-only code.
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: the problem here ultimately has to do with the way that the WF code works. I left some , but the bottom line is something like this: The WF code presently descends through binders but (generally speaking) opts not to prove WF conditions that involve higher-ranked regions. The strategy was described as "lazy" in the relevant RFC, but with the new universes code we can generally try to pursue something better, so I hope to get rid of it sooner or later. Anyway the idea is that whenever a higher-region is "expanded" with a particular value, we'll prove the WF at that point. So in this particular case we wind up with a type -- for this type to be WF, the region bound must hold. We are producing this constraint. If debug assertions are enabled, we ICE out because the constraint isn't supposed to include higher-ranked regions (here, ). But without debug assertions, we fail to detect that, and then we just wind up failing to prove it.

It's kind of hard to stumble across this ICE normally, because defaults to since we see the bound declared on . However, with generators, it occurs more readily because when constructing the generator witness, we replace the with a bound region (we replace all the internal regions in this way). Pursuant with the existing lazy strategy, I think the right fix is just for the wf code to ignore the constraint -- and that is a small patch to do. I will probably open a PR around this shortly.
Great, thank you! I can confirm that on latest nightly the issue is no longer there :D