-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 block with futures::stream::Buffered is not Send #104382
Comments
This comment isn't particularly helpful except for other contributors, but this is another manifestation of the common "futures have trouble with higher-ranked lifetimes and auto traits" issue that comes from lifetime erasure in generator interiors, I think... |
@compiler-errors out of curiosity are there any GitHub issues or Zulip chat histories worth reading that describe the general problem you're referring to? |
|
Out of curiosity, does the issue still show up if you do I would guess yes since drop tracking doesn't do much with lifetime issues, but it'd still be interesting to know. |
|
@khuey I've got a fix for that ICE coming up. |
…ice, r=oli-obk Pass `InferCtxt` to `DropRangeVisitor` so we can resolve vars The types that we encounter in the `TypeckResults` that we pass to the `DropRangeVisitor` are not yet fully resolved, since that only happens in writeback after type checking is complete. Instead, pass down the whole `InferCtxt` so that we can resolve any inference vars that have been constrained since they were written into the results. This is similar to how the `MemCategorizationContext` in the `ExprUseVisitor` also needs to pass down both typeck results _and_ the inference context. Fixes an ICE mentioned in this comment: rust-lang#104382 (comment)
Now, this issue can be close with #104753 ? |
No, #104753 only fixes this ICE (#104382 (comment)) mentioned by khuey. |
After #104753
|
rustc also seems to have trouble identifying the location of the error. In a large application with a top-level async fn that branches out to call many others, if you introduce code similar to that in the first comment in a function deep within the application, the |
Workaround to a known issue of rustc: rust-lang/rust#104382
Workaround to a known issue of rustc: rust-lang/rust#104382
Workaround to a known issue of rustc: rust-lang/rust#104382 Signed-off-by: Lin Yinfeng <lin.yinfeng@outlook.com>
Bring back the workaround required to circumvent rust-lang/rust#104382 This was accidentally removed with 1c511f2 Signed-off-by: Flavio Castelli <fcastelli@suse.com>
This issue was originally reported in rust-lang/futures-rs#2636, but it looks like a bug in the compiler.
Here is the example from that issue (posted by @Tuetuopay):
This should compile without issues, however rustc outputs this error message:
This occurs on current nightly (2022-11-11) and stable. Playground link: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=43484ffb5887c99e0845737c0241c853
There appears to be some issue in how the compiler checks the async block. If you call
.boxed()
on the stream before calling.buffered()
on it, the error goes away:This compiles without errors on current nightly and stable. Playground link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9c086487d1ff76b309796efa45846f67
The text was updated successfully, but these errors were encountered: