I'm running into this as well. You can work around it and get things working using a hack akin to this https://github.com/SunriseOS/core-futures-tls but it requires overriding libcore for every crate that needs #![feature(async_await)] which makes it difficult to do in library crates. TLS-free async fns would be cool.
(I'm sure this workaround is well-known but just posting for future readers that might come across this issue)
Not actively working on it, but i'm interested in giving it a go again, it's a gnarly one. Just moved cross-country and only now just returning to a somewhat stable life pattern.
That being said, if you want to do it and have the time, give it a go please!!
On September 15, 2019 6:30:39 AM EDT, Philipp Oppermann ***@***.***> wrote:
> I would like to tackle this since it's blocking a personal project.
Are you still working on this? I don't have much experience with the
Rust compiler, but maybe there is still a way I can help?
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
@cavedweller I took a detailed look at your work-in-progress implementation at benbrittain@11c9422 today. I think the next step would be to adjust the MIR transformation in librustc_mir/transform/generator.rs, which transforms generators into "normal" state machines. I assume that we would need to adjust the code generated for yield and resume to take the new arguments into account. Unfortunately, I have no experience with MIR transformations, so I fear that this is over my head. I'll try to read up about MIR and see if I can understand this transformation, but I can't promise anything.