The first code is HintCode.INFERENCE_FAILURE_ON_UNINITIALIZED_VARIABLE:
```dart
var a; // Hint: The type of v1 cannot be inferred without a type or initializer
dynamic b; // OK
var c = 7; // OK
```
This is currently only enabled via an analysis options file:
```yaml
analyzer:
language:
strict-inference: true
```
I could add it as a flag as well, but to start using this internally at Google,
we only need support in the analysis options file.
Bug: https://github.com/dart-lang/sdk/issues/33749
Change-Id: Id2a6afa7c3d724b44c20576c7f48869abcf4255c
Reviewed-on: https://dart-review.googlesource.com/c/93700
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>
This CL introduces
pkg/analyzer/lib/src/dart/analysis/experiments_generated.dart, which
will eventually be code generated from a YAML description of the
currently-allowed set of experimental flags.
Change-Id: Iabbefa8e5037573d4b4e7b7b4eb661c1698bd673
Reviewed-on: https://dart-review.googlesource.com/c/86220
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This updates more analyzer error codes to be generated
from the corresponding CFE error code.
Several of these analyzer error codes had multiple CFE error
codes mapped to them. In these situations, new analyzer error
codes were added to match the existing CFE error codes:
* EXTERNAL_FACTORY_WITH_BODY
* EXTERNAL_FACTORY_REDIRECTION
* CATCH_SYNTAX_EXTRA_PARAMETERS
Change-Id: Ib1cbb9e04d2092e4859e2cfadbcc85e03093f808
Reviewed-on: https://dart-review.googlesource.com/c/85431
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
The method addAll() is not really used.
We also use getErrorsForSource() only once in Analyzer / Server, and
only in tasks. So, we don't need Map<Source, errors>, and can use just
a single set of errors, which is cheaper than Map.
R=brianwilkerson@google.com
Change-Id: I001b0ce33ea496dd98191408245e3e82a47ff605
Reviewed-on: https://dart-review.googlesource.com/c/81140
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The parser now generates a ConstructorWithTypeArguments error and a new
handleInvalidTypeArguments event after a begin/endTypeArguments event pair
when those type arguments are in a syntatically invalid location.
For example: `new C.n<int>();` in
```
class C<T> { T f; C.n() {} }
main() { var x = new C.n<int>(); }
Most listeners handle this event by dropping the invalid type arguments,
but AstBuilder now preserves those invalid type arguments in the AST
to support better code quick-fixes/quick-assists/refactoring.
Change-Id: I5b22bd4903cd9ee3645936b9a108598b603cf9ca
Reviewed-on: https://dart-review.googlesource.com/c/79300
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
This updates the parser to recover when
* 'extend' or 'extends' is used rather than 'on' in a mixin declaration
* 'extend' or 'on' is used rather then 'extends' in a class declaration
This also introduces a new ExpectedInstead error message to better
communicate to the developer the keyword that should be used.
Fix https://github.com/dart-lang/sdk/issues/34563
Change-Id: Iafcb3d18db8ca3898c1e4dae74e5124c108ead48
Reviewed-on: https://dart-review.googlesource.com/77140
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
This reverts commit 836a1d7a88.
Revert "Don't use ClassElementImpl for now in override checking."
This reverts commit 58e44c1400.
Revert "large_class_declaration_test is slow now."
This reverts commit 56f6c52d58.
Revert "Add regression test for issue 34392."
This reverts commit ef7d144bc7.
Revert "Mixin declarations don't have supertype, fix isMoreSpecificThan()."
This reverts commit 95b8a19a20.
Change-Id: Icda9cf9091ef35acc8fd61ac5dc135b3717eba0a
Reviewed-on: https://dart-review.googlesource.com/76301
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Zach Anderson <zra@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>
Sam Rawlins