-
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
Implement #[must_not_suspend]
#88865
Conversation
cf1d0ec
to
2271376
Compare
This comment has been minimized.
This comment has been minimized.
@jyn514 the panic is:
Do you know what that could be? |
Seems like the I am not sure what this does, and if its needed for this lint, the last person to touch it seems to be @oli-obk in 7894509 ? |
30c2037
to
74ea163
Compare
this pr should be reviewable, except for I am unsure about if the is_ty_uninhabitated check is needed, currently its off |
This comment has been minimized.
This comment has been minimized.
There are a few things I do to make important info appear more obvious:
Sadly this is about as much as we can accomplish with the APIs we have today. |
@estebank I tried some options, I think |
@guswynn let's make a note (pun intended) to fix it later. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have any test cases that make sure dropping a must_not_suspend
value before a suspend point works as expected? I suspect we may have some trouble with this until I finish the liveness-based analysis for generators.
@eholk good point, it looks like |
// Returns whether it emitted a diagnostic or not | ||
// Note that this fn and the proceding one are based on the code | ||
// for creating must_use diagnostics | ||
pub fn check_must_not_suspend_ty<'tcx>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The complexity of this function seems ~okay to me, but I'm still wondering if the (discussed and dismissed in the RFC) marker trait (Suspend
?) approach would work better. The attribute could impl !Suspend
for structs, add it as a supertrait for traits and then the one caller to check_must_not_suspend_ty
could make the InferCtxt add an obligation for Suspend
to exist.
This would require some extra logic to make that obligation failure a lint instead of an error, so if we don't already have something like this, we should keep doing what we're doing here. Maybe just add the above paragraph as a comment for why we are implementing it this way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the choice basically "we decided against this in the RFC"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was never discussed in the RFC except for an honorable mention here
One additional test that I could think of would be a generic function that holds a generic argument over an await point and a caller to that generic function that uses a must_not_suspend type for the generic argument. Obviously this can't lint within the generic function, but we could probably inspect the generator created by the generic async function to see whether it stores said argument or whether it just uses it before its first resume. basically #[must_not_suspend]
struct No;
async fn shushspend() {}
async fn wheeee<T>(t: T) {
shushspend().await;
drop(t);
}
async fn yes() {
wheeee(No).await;
} |
@oli-obk interestingly your example actually triggers the lint fine (although, its not perfectly formatted, it doubles up just like the reference case) |
actually, no its triggering on the |
Added deduplication logic, currently at the hirid level, let me know what you think about what the ref test looks like now (It triggers now only on the value being borrowed, not the reference variable |
yea, I expected it to trigger in |
help: consider using a block (`{ ... }`) to shrink the value's scope, ending before the suspend point | ||
--> $DIR/dedup.rs:16:12 | ||
| | ||
LL | wheeee(No {}).await; | ||
| ^^^^^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this only makes sense where the value is held locally. If it was found in anther generator, then we should probably not emit this help
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is triggering on the No { }
value being held across the whee
yield point, I think? I believe that @eholk is improving this analysis
@bors r+ |
📌 Commit 08e0266 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (ce45663): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
@guswynn, Does that mean that warning should not fire when EDIT: I see there's #89562 for this already. |
implements #83310
Some notes on the impl:
must_use
lint. It's not shared, as the logic did divergemust_use
. I think this is a direct copy from themust_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. Themust_use
impl can do a single check at fn call stmt time, butmust_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 togenerator_interior.rs
, and I would need mentorship on that. @eholk and I are discussing it.reason
note pop out? right now it seems quite hiddenAlso, I am not sure if we should run perf on this
r? @nikomatsakis