-
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
Tracking Issue for must_not_suspend
lint (RFC #3014)
#83310
Comments
I am fairly busy right now, but I can pick this up in a few weeks' time. While researching the lint I dug into what changes would be required to the compiler and I'm fairly certain I have those written down somewhere. I would definitely appreciate any other pointers though. |
@rustbot claim |
@nikomatsakis @tmandry I've begun working on this implementation, but I would really appreciate if you or someone you can point to can drop some mentoring instructions to help me get started. The general idea I have so far is this:
Am I missing something? Right now my main questions are where the a type is constructed and where the propagation of the flag would fit in. |
As a note, I think made an implicit assumption of the propagation behavior in my previous comment. I think we should propagate the lint to nested types. I would like to do the work to apply this to the |
The other approach I was thinking of was provide a new |
Happy to help! Here are some bits of code to investigate to get started. First, you might want to look a bit at the Generators already have some logic to figure out what types outlive an await. We also have some logic to track why the type appears in that list, which we use for giving better error messages. Here is the code that adds a type into that set and tracks various spans associated with it: I think we could issue this lint exactly at this point -- we could basically analyze that type and determine whether it is "must not suspend". If so, we could issue the lint. Issuing a lint is done with some code roughly like this (from the |
@nikomatsakis thanks for the pointers! My initial plan was actually to follow the implementation of the Also, does my suggestion of using a query make sense? I was coming it at from a forward looking perspective, as there seem to be many other |
Bikeshed - using While there is precedent in the form of |
@bIgBV well, so type-flags can help to propagate through the types that are "visible". So for example I guess there's a question of which part to work on first. I personally would work on the code to create the lint first and have it fire in simpler cases, then come back and experiment with the best ways for it to fire. I have to go re-read the RFC: i still feel pretty strongly that we ought to make |
@nikomatsakis ah, that's fair. And yes, I agree, I think we need to solve the problem of propagating attributes for both this and the |
@bIgBV oh, interesting thought |
@bIgBV let me know if you are still working on this! I may start looking at it this weekend |
Just wondering, will this attribute be added to selected |
@Kobzol, appropriate |
Implement `#[must_not_suspend]` implements rust-lang#83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared, as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects), like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this, as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC, and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time, but `must_not_suspend` would need to answer the question: "for some value X with type T, find any fn call that COULD have produced this value". That would require significant changes to `generator_interior.rs`, and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also, I am not sure if we should run perf on this r? `@nikomatsakis`
#89303 adds |
The |
I think that's how lints usually work. |
No, lints can definitely be landed as unstable first, it's what I would expect here. There's not much risk since they're mostly just "a name", but we should still avoid accidental stabilizations. |
Ok, I opened an issue: #89798. |
interesting, I did not know this |
I'm wondering: can |
@yvt the |
@guswynn Thank you for the answer. Actually I'm looking for something stronger than pinning, a guarantee that |
changelog: [`await_holding_invalid_type`] This lint allows users to create a denylist of types which are not allowed to be held across await points. This is essentially a re-implementation of the language-level [`must_not_suspend` lint](rust-lang/rust#83310). That lint has a lot of work still to be done before it will reach Rust stable, and in the meantime there are a lot of types which can trip up developers if they are used improperly.
changelog: [`await_holding_invalid_type`] This lint allows users to create a denylist of types which are not allowed to be held across await points. This is essentially a re-implementation of the language-level [`must_not_suspend` lint](rust-lang/rust#83310). That lint has a lot of work still to be done before it will reach Rust stable, and in the meantime there are a lot of types which can trip up developers if they are used improperly.
Add `await_holding_invalid_type` lint changelog: [`await_holding_invalid_type`] This lint allows users to create a denylist of types which are not allowed to be held across await points. This is essentially a re-implementation of the language-level [`must_not_suspend` lint](rust-lang/rust#83310). That lint has a lot of work still to be done before it will reach Rust stable, and in the meantime there are a lot of types which can trip up developers if they are used improperly. I originally implemented this specifically for `tracing::span::Entered`, until I discovered #8434 and read the commentary on that PR. Given this implementation is fully user configurable, doesn't tie clippy to any one particular crate, and introduces no additional dependencies, it seems more appropriate.
This is a tracking issue for the RFC 3014 (rust-lang/rfcs#3014).
The feature gate for the issue is
#![feature(must_not_await_lint)]
.Status: This is waiting on more precise generator captures to reduce false positives before stabilizing and turning the lint on by default.
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
instructions?)
Unresolved Questions
Implementation history
#[must_not_suspend]
#88865The text was updated successfully, but these errors were encountered: