See #35908.
Change-Id: Icbbb28920447362407e53c45b816474d1ab9e280
Reviewed-on: https://dart-review.googlesource.com/c/94021
Commit-Queue: Paul Berry <paulberry@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
... and no longer generate handleLiteralSet or handleLiteralMap.
In addition, a new hasSetEntry parameter has been added to the
handleLiteralSetOrMap event generated by the parser to support
existing behavior. Once all listeners have implemented
unified collections and that feature is enabled by default,
the hasSetEntry parameter can be removed.
This is the third of several CLs updating the parser and its listeners
to conform to the unified collection spec:
https://github.com/dart-lang/language/pull/200
Change-Id: Ia305eab1f720658f357ac4102b0b0c8128d16997
Reviewed-on: https://dart-review.googlesource.com/c/93963
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Several places in the analyzer and the analysis server were using
hardcoded integers to represent precedence, rather than referring to
constants defined in the front_end. This led to some subtle
off-by-one errors, because the old analyzer convention (prior to
integration with the front_end parser) used 0 to represent the lowest
precedence of an expression (and -1000 to represent the precedence of
non-expressions), whereas the front_end convention is for 1 to
represent the lowest precedence of an expression. As far as I can
tell there was no user visible impact, but it made it very difficult
to reason about operator precedence.
This CL updates the analyzer and the analysis server so that they
don't hardcode any precedence values; instead they refer to named
constants in the front end.
In a follow-up CL I'll reduce some hardcoded precedence numbers in the
front end itself.
Change-Id: Id3869afeb83042cc7d6630a0a4a0533a07058736
Reviewed-on: https://dart-review.googlesource.com/c/93964
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Change-Id: I492e8ce5303713cca0c742deeb53f670ebd21f84
Reviewed-on: https://dart-review.googlesource.com/c/93849
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
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>
We already can store List<double>, but not `double` itself.
The LinkedConstantValue data structure I'm working on will have a
field of type `double`, so I need to support in in the generator.
R=paulberry@google.com
Change-Id: Ic5aa3a9a7266afabe6c64214fd68097fbebda4e8
Reviewed-on: https://dart-review.googlesource.com/c/93820
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
BTW, I'm in doubt about using global variable in AnalysisOption directly.
Maybe make it a writable option, like `lintRules`, so that we don't use
static data? I realize that most probably we set `lintRules` into
AnalysisOptions just because it is just convenient to separate registry
and enable rules, not because we want separation from static data.
R=brianwilkerson@google.com, pquitslund@google.com
Bug: https://github.com/dart-lang/linter/issues/1440
Change-Id: I44f5c8cdc41eaead926fbbe250063c41bd888a78
Reviewed-on: https://dart-review.googlesource.com/c/93844
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
IntelliJ had a regression for a short time, so sorting did not work.
R=brianwilkerson@google.com
Change-Id: I0b631e8061bc3139f0848492e35c583b6bfb4ec4
Reviewed-on: https://dart-review.googlesource.com/c/93747
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
As a temporary workaround, we ignore types when comparing default values for overrides.
See https://github.com/dart-lang/sdk/issues/35908 for a more detailed
explanation for why this is necessary. Once summaries properly record
types of constant values, we will be able to revert this hack.
Change-Id: I04728231338274a088656a629e303c0f1745466d
Reviewed-on: https://dart-review.googlesource.com/c/93642
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is the first of several CLs updating the parser and its listeners
to conform to the unified collection spec:
https://github.com/dart-lang/language/pull/200
Change-Id: I7750bc4b029f3963b2df77dab3630775ce921bba
Reviewed-on: https://dart-review.googlesource.com/c/93740
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
If a method parameter is used in unconditional control flow in a way
that a `null` value would directly lead to an exception (i.e. by
dereferencing it, or by passing it to a method that requires a
non-nullable value), this is treated as implying that the method
parameter is intended to be non-nullable.
Change-Id: I4f55e4c95b3cfaee0a2ba9367b47d51083e0b7b1
Reviewed-on: https://dart-review.googlesource.com/c/93363
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
With task model being removed, there is nothing to compare to.
We now use just textual dumps of library elements.
R=brianwilkerson@google.com, paulberry@google.com
Change-Id: I5693548b8b71dd1318d761dcacbaf88a376a2f54
Reviewed-on: https://dart-review.googlesource.com/c/93321
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This reverts commit 5d6bab4ed2.
Reason for revert: this change is API incompatible when rolling into mono-repo.
Original change's description:
> Add ExecutableElement(s) based InheritanceManager3, and switch analyzer to it.
>
> Change-Id: I9d87619e05ae769f4df6a6ba26cd7901c7c98510
> Reviewed-on: https://dart-review.googlesource.com/c/93141
> Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
TBR=scheglov@google.com,brianwilkerson@google.com
Change-Id: I98d478f56e8aea037cbcc8b6cb940c36edb732fd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/93440
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Change-Id: I6ec0556c0ec42971dee67a784c7c5f884862ac03
Reviewed-on: https://dart-review.googlesource.com/c/93284
Commit-Queue: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Change-Id: I04b4fc38ecb558edcc946b3fad122febec57ed2a
Reviewed-on: https://dart-review.googlesource.com/c/93065
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Auto-Submit: Brian Wilkerson <brianwilkerson@google.com>
These declarations are already available through the library element
model.
R=brianwilkerson@google.com
Change-Id: I9d3d274a8bf4ad28c10f04afc30fa11436cd0f6a
Reviewed-on: https://dart-review.googlesource.com/c/92848
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
