Remove TLS dependency from async/await

[benbrittain]

Futures currently have a dependency on TLS for storing a pointer to Context<'_>.
https://github.com/rust-lang/rust/blob/master/src/libstd/future.rs#L116

This makes usage in no_std environments quite difficult.

[benbrittain]

I would like to tackle this since it's blocking a personal project.

cc/ @cramertj @eddyb @nikomatsakis @Zoxc

[xurtis]

Duplicate of rustasync/team#42

[xurtis]

There's also some additional background discussion on the rust-internals discourse.

[cramertj]

Duplicate of rustasync/team#42

Not sure if you were suggesting this, but I don't think we should be using other repo's issues to track changes to rustc.

[xurtis]

I mean, nor do I but that is where most of the existing discussion is. It may be worth closing the other thread to try and avoid splitting the discussion over two issues on separate repos.

[TomCrypto]

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)

[phil-opp]

@cavedweller

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?

[benbrittain]

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: @cavedweller > 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: #62918 (comment)

[phil-opp]

@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.

[jonas-schievink]

This is essentially a duplicate of #56974, so closing in favor of that.