There is a seeming parse error in typedefs, and an open question on the
issue (33343) about what to do when a generic function type is inferred.
Otherwise this seems ready to go.
Bug: 33343
Change-Id: I10d2ea9b6ca26ed2c6ff6b24ffe5008fc4797ef2
Reviewed-on: https://dart-review.googlesource.com/61109
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Does not handle the other half of #33343, rejecting generic function
types as type arguments.
This revealed a secondary minor issue which was easy enough to fix. Type
arguments were not resolved within bounds:
class C<T extends S Function<S>(S)> {}
this would report 'undefined class S' for the return and parameter types
`S`. I almost split this into a separate CL, but, these two CLs are tied
together inherently by the tests case. Easy to solve at once.
Bug: 33343
Change-Id: Ib34a04d90be08d8d6c6f21a9d485a452017585ba
Reviewed-on: https://dart-review.googlesource.com/61103
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Paul Berry <paulberry@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>
This follows Leaf's simplified suggestion. As a temporary hack it
assumes that the mixin passes its type parameters through to its
superclass constraint unchanged.
Change-Id: I091b44005d6364a91e20578f2ff6340334b1fab6
Reviewed-on: https://dart-review.googlesource.com/38040
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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 displayName of an anonymous closure is a blank String, resulting in messages like:
[error] The return type 'String' is not a 'int', as defined by the method ''.
After this change, an error might instead look like:
$ xcodebuild/ReleaseX64/dart-sdk/bin/dartanalyzer --strong 26056.dart
Analyzing 26056.dart...
error • The return type 'String' isn't a 'int', as defined by anonymouse closure at 26056.dart:6:28 • return_of_invalid_type
1 error found.
Bug: https://github.com/dart-lang/sdk/issues/26056
Change-Id: I4003eea22cb23e0b06479482c06d5ce8a936c756
Reviewed-on: https://dart-review.googlesource.com/28382
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The analyzer used to emit a warning when a type parameter to a generic
method was used in an "is" check. This warning was there to help
users write code that worked correctly on both Dart 1.0 and 2.0. Now
that 2.0 generic methods are being more broadly supported and used,
this warning is blocking further library work, and is being removed.
Fixes https://github.com/dart-lang/sdk/issues/30530
Bug:
Change-Id: I70395305ad082aee3072b5beeb0b1b7f7883391b
Reviewed-on: https://dart-review.googlesource.com/29821
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
* `as` clause and `deferred as` clause processing pushed
into a new processImportPrefixOpt method.
* New handleImportPrefix event for communicating
`as` clause and `deferred as` clause to the listeners.
* Several new more detailed error messages for out of order
clauses and keywords in the import directive.
Change-Id: I133842c7225403fa000ca1cf0e49af9f8a011386
Reviewed-on: https://dart-review.googlesource.com/8580
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
- New handleRecoverImport event
for clauses in import directive that are out of order
- New error codes for
Duplicate prefix
Prefix after combinator
Change-Id: I0fea7ad4b4014a0b8578d3982e0515fe85044854
Reviewed-on: https://dart-review.googlesource.com/7980
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Rather than have multple fine grained error codes for each type
of modifier in each situation, this CL adds a new analyzer
ParserErrorCode.EXTRANEOUS_MODIFIER parallel to the fast parser
error code and updates the AstBuilder to generate that error
rather than ParserErrorCode.ABSTRACT_CLASS_MEMBER.
My goal is to review each analyzer error code similar to
ParserErrorCode.ABSTRACT_CLASS_MEMBER and map each to the same
ParserErrorCode.EXTRANEOUS_MODIFIER error code.
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2999303002 .
Brian Wilkerson