[linter] Makes `unawaited_futures` report for `FutureOr`
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
// This rule does concern itself with `FutureOr`.Dead comment?
It's easy to forget `await` in `async` methods as naming conventions usually don'tThanks for this!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// This rule does concern itself with `FutureOr`.Dead comment?
I've copied this over from `discarded_futures`. Would you prefer I remove these from both?
It's easy to forget `await` in `async` methods as naming conventions usually don't| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
// This rule does concern itself with `FutureOr`.FMorschelDead comment?
I've copied this over from `discarded_futures`. Would you prefer I remove these from both?
I haven't looked at `discarded_futures`, but the point of the comment in this location was presumably to explain why the absence of handling for `FutureOr` wasn't considered a bug. It was impossible for a reader to know why it wasn't there without the comment. (Not that the comment really answered the question anyway.)
Now that `FutureOr` is handled, the comment isn't helpful. A reader is unlikely to wonder "why is this handling FutureOr?" (nor would the revised comment answer that question if they did).
Hence the request to delete the comment with this change.
Your choice as to whether to delete it from `discarded_futures`.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
FMorschelDead comment?
Brian WilkersonI've copied this over from `discarded_futures`. Would you prefer I remove these from both?
I haven't looked at `discarded_futures`, but the point of the comment in this location was presumably to explain why the absence of handling for `FutureOr` wasn't considered a bug. It was impossible for a reader to know why it wasn't there without the comment. (Not that the comment really answered the question anyway.)
Now that `FutureOr` is handled, the comment isn't helpful. A reader is unlikely to wonder "why is this handling FutureOr?" (nor would the revised comment answer that question if they did).
Hence the request to delete the comment with this change.
Your choice as to whether to delete it from `discarded_futures`.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
The lint is now reporting some cases that weren't reported before, in the analysis_server, flutter, and internal code. You can fix the first two, but someone else will need to fix the internal code.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The lint is now reporting some cases that weren't reported before, in the analysis_server, flutter, and internal code. You can fix the first two, but someone else will need to fix the internal code.
I'm aware. I'm working on the SDK changes, and I'll add a comment to the issue when I open the Flutter PR.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[!g!]();Can we add a test like this that uses `unawaited`. I'm getting analyzer errors when I try this, highlighting the argument to `unawaited` saying:
The argument type 'FutureOr<int>' can't be assigned to the parameter type 'Future<void>?'. #argument_type_not_assignable
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[!g!]();Can we add a test like this that uses `unawaited`. I'm getting analyzer errors when I try this, highlighting the argument to `unawaited` saying:
The argument type 'FutureOr<int>' can't be assigned to the parameter type 'Future<void>?'. #argument_type_not_assignable
I'm not sure I understand the request. It was defined at https://github.com/dart-lang/sdk/issues/59877 that we wouldn't accept `FutureOr` in `unawaited`. We need to use `//ignore` in that case.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
correctionMessage: "Try adding an 'await' or wrapping the expression with 'unawaited'."We don't want to get too wordy here, but I think we should indicate that 'unawaited' won't work for FutureOr-typed expressions. Maybe just a parenthetical "(if it is a Future)".
expression in a call to `unawaited()`.We need to mention here that this doesn't work with the FutureOr type (it probably won't help _too_ many users, but if a user tries to use unawaited, and gets stuck, and comes to the docs, this is a good place to help them).
[!g!]();FMorschelCan we add a test like this that uses `unawaited`. I'm getting analyzer errors when I try this, highlighting the argument to `unawaited` saying:
The argument type 'FutureOr<int>' can't be assigned to the parameter type 'Future<void>?'. #argument_type_not_assignable
I'm not sure I understand the request. It was defined at https://github.com/dart-lang/sdk/issues/59877 that we wouldn't accept `FutureOr` in `unawaited`. We need to use `//ignore` in that case.
Ah, I see. I think we should document this in one or two places. But I'll use `// ignore` to suppress.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
correctionMessage: "Try adding an 'await' or wrapping the expression with 'unawaited'."We don't want to get too wordy here, but I think we should indicate that 'unawaited' won't work for FutureOr-typed expressions. Maybe just a parenthetical "(if it is a Future)".
Done
We need to mention here that this doesn't work with the FutureOr type (it probably won't help _too_ many users, but if a user tries to use unawaited, and gets stuck, and comes to the docs, this is a good place to help them).
Done
FMorschelCan we add a test like this that uses `unawaited`. I'm getting analyzer errors when I try this, highlighting the argument to `unawaited` saying:
The argument type 'FutureOr<int>' can't be assigned to the parameter type 'Future<void>?'. #argument_type_not_assignable
Samuel RawlinsI'm not sure I understand the request. It was defined at https://github.com/dart-lang/sdk/issues/59877 that we wouldn't accept `FutureOr` in `unawaited`. We need to use `//ignore` in that case.
Ah, I see. I think we should document this in one or two places. But I'll use `// ignore` to suppress.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
FMorschelThe lint is now reporting some cases that weren't reported before, in the analysis_server, flutter, and internal code. You can fix the first two, but someone else will need to fix the internal code.
I'm aware. I'm working on the SDK changes, and I'll add a comment to the issue when I open the Flutter PR.
I've commented on the issue too but the PR is https://github.com/flutter/flutter/pull/189198
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
correctionMessage: "Try adding an 'await' or wrapping the expression with 'unawaited'."FMorschelWe don't want to get too wordy here, but I think we should indicate that 'unawaited' won't work for FutureOr-typed expressions. Maybe just a parenthetical "(if it is a Future)".
Done
I'd rather have two codes (with a shared name) so that the suggestion only shows up when it's appropriate. That is, for a `FutureOr` the user would see
Try adding an 'await'.
And for a normal `Future` the user would see
Try adding an 'await' or wrapping the expression with 'unawaited'.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
correctionMessage: "Try adding an 'await' or wrapping the expression with 'unawaited'."FMorschelWe don't want to get too wordy here, but I think we should indicate that 'unawaited' won't work for FutureOr-typed expressions. Maybe just a parenthetical "(if it is a Future)".
Brian WilkersonDone
I'd rather have two codes (with a shared name) so that the suggestion only shows up when it's appropriate. That is, for a `FutureOr` the user would see
Try adding an 'await'.
And for a normal `Future` the user would see
Try adding an 'await' or wrapping the expression with 'unawaited'.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
FMorschelThe lint is now reporting some cases that weren't reported before, in the analysis_server, flutter, and internal code. You can fix the first two, but someone else will need to fix the internal code.
FMorschelI'm aware. I'm working on the SDK changes, and I'll add a comment to the issue when I open the Flutter PR.
I've commented on the issue too but the PR is https://github.com/flutter/flutter/pull/189198
The Flutter PR has landed. As soon as the internal code is fixed, this can land. Thanks!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
Thanks for the bots, @sraw...@google.com! Everything is in order now. I wasn't aware each sub-diagnostic needed an entry in error_fix_status.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
Thanks for the bots, @sraw...@google.com! Everything is in order now. I wasn't aware each sub-diagnostic needed an entry in error_fix_status.
I don't think https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8676649034613111809/+/u/test_results/new_test_failures__logs_ has any relation to this change.
If it does, can someone explain it to me?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
FMorschelThanks for the bots, @sraw...@google.com! Everything is in order now. I wasn't aware each sub-diagnostic needed an entry in error_fix_status.
I don't think https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8676649034613111809/+/u/test_results/new_test_failures__logs_ has any relation to this change.
If it does, can someone explain it to me?
I don't see how it could be related. It isn't failing on the non-`try` bot, so I'll try re-running it.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[linter] Makes `unawaited_futures` report for `FutureOr`
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Just a question:
Would this case trigger a warning?
```dart
FutureOr<int> maybeAsync(bool sync) {
return sync ? 123 : Future.value(456);
}
Future<int> alwaysAsync1(bool sync) {
print("Calling maybeAsync($sync)...");
return maybeAsync(sync);
}Future<int> alwaysAsync2(bool sync) async {
print("Calling maybeAsync($sync)...");
return maybeAsync(sync);
}
```I think neither of these cases should trigger a warning.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Just a question:
Would this case trigger a warning?
```dart
FutureOr<int> maybeAsync(bool sync) {
return sync ? 123 : Future.value(456);
}Future<int> alwaysAsync1(bool sync) {
print("Calling maybeAsync($sync)...");
return maybeAsync(sync);
}Future<int> alwaysAsync2(bool sync) async {
print("Calling maybeAsync($sync)...");
return maybeAsync(sync);
}
```I think neither of these cases should trigger a warning.
Only the `Future` inside `maybeAsync` if you enable `discarded_futures`. The other cases won't trigger either `discarded_futures` or `unawaited_futures` because you are "using" the value (with the `return`).
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Just a question:
Would this case trigger a warning?
```dart
FutureOr<int> maybeAsync(bool sync) {
return sync ? 123 : Future.value(456);
}Future<int> alwaysAsync1(bool sync) {
print("Calling maybeAsync($sync)...");
return maybeAsync(sync);
}Future<int> alwaysAsync2(bool sync) async {
print("Calling maybeAsync($sync)...");
return maybeAsync(sync);
}
```I think neither of these cases should trigger a warning.
Additionally, I don't think this case should trigger a warning either:
```dart
FutureOr<int> alwaysAsync3(bool sync) {
print("Calling maybeAsync($sync)...");
return maybeAsync(sync);
}
FutureOr<int> alwaysAsync4(bool sync) async {
print("Calling maybeAsync($sync)...");
return maybeAsync(sync);
}
```
---
Note that here the `Future` is being returned directly, which is equivalent to the original code:
```dart
FutureOr<int> maybeAsync(bool sync) {
if (sync) {
return 123;
} else {
return Future<int>.value(456);
}
}
```| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
All still fine cases, no report will happen. This change is meant to help you with:
```dart
void main() async {
futureOrFunc(); //Nothing previously but now we get a lint
futureFunc(); //Linted
}
Future<void> futureFunc() async {
// Expects something of `futureOrFunc` to be done
}FutureOr<void> futureOrFunc() async {}
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I'm the author of `async_extension`: https://github.com/eneural-net/async_extension
I'm exploring use cases where a new lint warning might be beneficial or potentially problematic.
I'm generally in favor of applying `unawaited_futures` to `FutureOr` values, but only in cases where it helps identify a genuinely missing `await`.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This change makes nothing but trigger the same cases we have for `Future` but for `FutureOr`, so it should be fine.
You might be interested in the _actually new_ lint and warning diagnostics `async_return_with_no_await` and `unawaited_return_in_try_block`:
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |