-
Notifications
You must be signed in to change notification settings - Fork 31
Create rule S7521: Coroutine objects should be awaited #5105
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
base: master
Are you sure you want to change the base?
Conversation
e3e2d68
to
a1fd11a
Compare
(visible only on this page) | ||
|
||
=== Message | ||
Await this coroutine or store it in a variable to be awaited 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.
With this approach I actually think we could implement it in sonar-python
without DBD...
Finding the absence of await
on the stored object would actually be difficult, even with DBD.
Probably worth discussing with someone from DBD before any implementation though, and depending on that, we can adapt the message.
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.
With this approach, I agree.
The behavior and limitations should be clearly defined in the tests.
In the long term, I really think DBD or a taint analysis engine are the more robust implementation
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.
That makes sense!
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.
I left some small comments but LGTM!
rules/S7521/python/rule.adoc
Outdated
|
||
== How to fix it | ||
|
||
Always use the `await` keyword when calling a coroutine function or any other awaitable object (like a `Task` or `Future`). Alternatively, you can schedule the coroutine to run using methods like `asyncio.create_task()`, but be sure to save and await the resulting task. |
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.
I think the recommendation should be broader and use keywords like TaskGroup or Nursery to help people look for the correct replacements
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.
I made a slight change in the recommendation. That said, I think the rule is a bit more generic than the others we have created so far, and probably targets someone who simply forgot to add the await
keyword. I feel that by referencing Nursery
, I'm now tempted to have a "How to fix in Trio" section which may not be super relevant here.
Hopefully we hit a middle ground with the new wording.
(visible only on this page) | ||
|
||
=== Message | ||
Await this coroutine or store it in a variable to be awaited 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.
With this approach, I agree.
The behavior and limitations should be clearly defined in the tests.
In the long term, I really think DBD or a taint analysis engine are the more robust implementation
}, | ||
"tags": [ | ||
"async", | ||
"asyncio", |
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.
We might as well add the two other libraries, since it it not specific to any of them
00bb150
to
b1d5941
Compare
|
|
You can preview this rule here (updated a few minutes after each push).
Review
A dedicated reviewer checked the rule description successfully for: