This is necessary because the internal code base considers a test file
to fail if it doesn't run any tests.
Alternative fixes considered:
- Put a dummy test in hint_code_test.dart
- Rename hint_code_test.dart to a name that doesn't end in _test.dart
Change-Id: I64fa2be7c76b4d2a85ee9b46ba1a1c21ae2903ae
Reviewed-on: https://dart-review.googlesource.com/c/94800
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The task model is still allowed in analyzer tests since we still have
some unit tests of non-task-model functionality that rely on the task
model to do their testing (see #35734).
Unit tests whose sole purpose was to test the task model have been
removed. Test files that now empty have been removed. Non-empty test
files that now contain no tests of their own have had their `main`
functions removed, and have been renamed so that the testing
infrastructure will no longer attempt to run them.
Change-Id: I8b4d0b2dde9337c4e1fe91e443a2c9da6eee8f4f
Reviewed-on: https://dart-review.googlesource.com/c/90720
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Also add a superclass to BasicWorkspace and PubWorkspace, since the bulk of their
implementation is shared; Only find() and findPackageFor() need to be separate;
the package mapping and resolving can be shared.
Change-Id: I13932d6947d6dc28fc7223594e5bd2526f12f573
Reviewed-on: https://dart-review.googlesource.com/c/89167
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Example code:
```dart
import 'package:meta/meta.dart';
class A {
@literal
const A();
@literal
const A.named();
}
var a = A();
var b = const A();
const c = A();
var d = new A();
var e = new A.named();
```
Produces:
Analyzing b.dart...
hint • This instance creation must be 'const', because the A constructor is marked as '@literal' at b.dart:11:9 • non_const_call_to_literal_constructor
hint • This instance creation must be 'const', because the A constructor is marked as '@literal' at b.dart:14:9 • non_const_call_to_literal_constructor
hint • This instance creation must be 'const', because the A.named constructor is marked as '@literal' at b.dart:16:9 • non_const_call_to_literal_constructor
3 hints found.
Bug: https://github.com/dart-lang/sdk/issues/34259
Change-Id: Iba10e5e0a0b2d0f7e99556cd6c201cea229ad675
Reviewed-on: https://dart-review.googlesource.com/c/88422
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
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>
Brian Wilkerson