If a function expression is used in a context that expects a return type
other than dynamic/void/Null, issue a hint if that function has a block
body and is missing a `return` statement.
Change-Id: Ia55212abd84f5718343cf7401b87aba2891d6446
Reviewed-on: https://dart-review.googlesource.com/66340
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This CL introduces new Factory/TypeInferenceListener methods to
communicate details about types that are literally named in the source
code.
Previously, when an expression like `x as List<int>` was analyzed, the
resolution information about `List<int>` was communicated to the
analyzer via a kernel DartType, forcing the analyzer to walk the type
representation, applying each of its constituent parts to the
corresponding part of the AST for `List<int>`. This was a lot of work
for the analyzer, it failed to resolve parts of invalid types (such as
`List<int, String>), and it didn't pave the way toward moving to the
Factory API.
The new approach is for information about each type appearing in the
syntax to be communicated to the analyzer at the time the BodyBuilder
converts it to a DartType. So for an invalid type like `List<int,
String>`, the resolution of `String` is communicated to the analyzer
at the time it is converted to a DartType; later, when `String` is
discarded (because `List` only accepts one type parameter), no crucial
information is lost, because the analyzer already knows the resolution
of `String`.
Work still to be done has been captured in issues:
- #33844: References to type parameter elements are not translated
- #33845: Function typed formal parameters are not handled
- #33846: Function types using `Function` syntax are not yet handled
Change-Id: I96dd9b6f3eb573b0b7a46335e8644c59fb78bae7
Reviewed-on: https://dart-review.googlesource.com/64262
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This will allow us later switch from applying resolution to parsed
AST to directly generating resolved AST, when we get to this.
New failing tests are because of absence of annotations, constant
values (initializers, default values), and constructor initializers
in outlines.
We also don't get errors for constant value computing, hence some
tests are now passing, but not by the reason we intended to test.
R=brianwilkerson@google.com, paulberry@google.com
Change-Id: I5b45da592563af02c45e8cda160ccd24487c3591
Reviewed-on: https://dart-review.googlesource.com/61743
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This gets the tests running again. I'll follow this up with CLs that
reshape the ResolutionStorer API to match the Factory API we're
building, and then after that we can transition the code over to
calling the Factory API directly.
Fixes#33504Fixes#32258
Change-Id: I105841ed5b2ed1198ec5e3e7387f694c61d36ca7
Reviewed-on: https://dart-review.googlesource.com/61101
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
We have decided to move to a different API for Fasta/Analyzer
integration, one that doesn't involve compiling to Kernel or observing
type inference. The listener API will become broken, so let's just
remove it before that happens.
We lose the ability to trace type inference so let's restore that
ability next. The analyzer's resolution storer is not used, but that
code has been left. The resolution applier will no longer work
without the resolution storer, so those tests have been disabled.
Change-Id: If9ac5aba2d5de7788d8a65f7fa8410599e636d21
Reviewed-on: https://dart-review.googlesource.com/42400
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This adds 2 new hints `NULL_AWARE_BEFORE_OPERATOR` and `NULL_AWARE_IN_LOGICAL_OPERATOR`.
The previous `NULL_AWARE_IN_CONDITION` hint didn't catch null-aware issues in assigments or expression statements with logical operators. `NULL_AWARE_IN_LOGICAL_OPERATOR` handles those cases.
`NULL_AWARE_BEFORE_OPERATOR` handle issue like `a?.b + c`.
Closes#32239https://github.com/dart-lang/sdk/pull/32239
GitOrigin-RevId: 8b20ec5f7ea7901b1d0889eaf54ad0660c6e3f76
Change-Id: I36ada68c13dd0e1dd2bfd829ae25ce3ba9c8f402
Reviewed-on: https://dart-review.googlesource.com/42360
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This reverts commit 09eed74a8a.
Reason for revert: Too much SDK code is not yet compliant.
Original change's description:
> Make `void` a static warning to use almost everywhere.
>
> Changed the hint to a StaticWarningCode, since that's the new spec'd
> error type and the hint is no longer needed.
>
> Added a new set of methods to test the cases.
>
> Didn't try to solve the problem generally ("all usages except ... are
> errors" means it easier, in theory, to make a ReportVoidExpressions
> style visitor that catches absolutely all types) because most of the
> work is actually about suppressing errors that are no longer needed.
> Ie, from NO_SUCH_METHOD to USAGE_OF_VOID_RESULT which means we have to
> put the void handling logic into each AST method specially anyway.
>
> Some redundant tests removed.
>
> Don't flag: ternaries, void -> void assignments, void returns in
> dynamic.
>
> Change-Id: Ief8035dcfe582b36b6372180ddcf4e453d320d9c
> Reviewed-on: https://dart-review.googlesource.com/37441
> Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
> Reviewed-by: Leaf Petersen <leafp@google.com>
TBR=leafp@google.com,scheglov@google.com,mfairhurst@google.com
Change-Id: I13ee4c6939468d35506779ade637a040833632f4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/39848
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Changed the hint to a StaticWarningCode, since that's the new spec'd
error type and the hint is no longer needed.
Added a new set of methods to test the cases.
Didn't try to solve the problem generally ("all usages except ... are
errors" means it easier, in theory, to make a ReportVoidExpressions
style visitor that catches absolutely all types) because most of the
work is actually about suppressing errors that are no longer needed.
Ie, from NO_SUCH_METHOD to USAGE_OF_VOID_RESULT which means we have to
put the void handling logic into each AST method specially anyway.
Some redundant tests removed.
Don't flag: ternaries, void -> void assignments, void returns in
dynamic.
Change-Id: Ief8035dcfe582b36b6372180ddcf4e453d320d9c
Reviewed-on: https://dart-review.googlesource.com/37441
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
The latter was already passing (because FutureOr<void>.isVoid is true
already, which was a condition of early bailout for MISSING_RETURN).
The former was not working, but is now handled.
Unit tests for each.
Change-Id: I0f6e7ddc71940517c5746c1a5431f4491ee2eef3
Reviewed-on: https://dart-review.googlesource.com/37440
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
The old implementation only validated a whitelisted set of use cases,
so it would often miss important subexpressions. The new
implementation is based on a RecursiveAstVisitor so by default it
visits all subexpressions; we use overrides for the specific cases
where it's not necessary to visit all subexpressions.
Fixes#31963.
Change-Id: Icb9833f51bef26874f655cd2ba4ffc509bfffef3
Reviewed-on: https://dart-review.googlesource.com/36803
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Keerti Parthasarathy