There is no distinction between them from the langauge of view anymore.
This is a preparatory step before reporting super-invoked abstract
class members as errors, which we should do according to the issue.
Which, in turn, is for consistency between repoting corresponding
error for super-invoked, but not concrete members in mixin applications.
R=brianwilkerson@google.com
Bug: https://github.com/dart-lang/sdk/issues/33662
Change-Id: I00e8f185dbbdd1ffac88c500394a1e1497be6f9a
Reviewed-on: https://dart-review.googlesource.com/74481
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
AnalysisDriverResolutionTest is partially updated, about 30 failing
tests added. I will get back to it in a following CL, it is not
directly CFE integration, but updated understanding how we want to
resolve. For example we don't need types for non-expression identifiers.
Change-Id: I3daddbb6c66ffad7a726f3313a1199fd7387aa04
Reviewed-on: https://dart-review.googlesource.com/71883
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
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 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>
This warning fires if a top level initializer depends on the type of a
method whose type is subject to type inference. This warning is
needed because the analyzer implementation of top level type inference
doesn't guarantee that the method type will be inferred prior to the
initializer, so it's possible that type inference will produce an
incorrect result. See #31925 for more details.
Change-Id: Iec048d2638877c16ae11a87eae0382b7352f726c
Reviewed-on: https://dart-review.googlesource.com/36841
Reviewed-by: Konstantin Shcheglov <scheglov@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>
If an implicitly typed top level variable or field depends on an
implicitly typed instance getter or instance field, the analyzer
implementation of type inference isn't guaranteed to infer the
depended-upon field first, therefore the type might be inferred
incorrectly.
The new front end doesn't have this problem, so the user's code will
execute correctly at runtime, but they might get confusing results
from the analyzer. To alert users of this problem, we issue a
compile-time warning whenever an implicitly typed top level variable
or field depends on an implicitly typed instance getter or instance
field.
Change-Id: I100bcbe1a76472bcb7d493eb12e4a3e2d0605e79
Reviewed-on: https://dart-review.googlesource.com/35385
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In particular, enforce that a method annotated with @visibleForTesting can only
be referenced from within the declaring library, or within a file that has
"/test" in its path. This allows @visibleForTesting methods to be accessed from
test files, or files in "/testing" folders, etc.
Bug: https://github.com/dart-lang/sdk/issues/28273
Change-Id: I3c19f73be330c49face7e3203879742d514bca74
Reviewed-on: https://dart-review.googlesource.com/27201
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Shows a hint when `Function` is used:
- as a class name,
- in an extends clause,
- in an implements clause,
- in a with clause.
The `Function` may or may not point to the core's `Function`. All uses of `Function` in these contexts are deprecated.
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2643073002 .
Brian Wilkerson