Follow up for https://dart-review.googlesource.com/c/sdk/+/381704
I think we don't need to canonicalize it at all, and pay for map lookup.
If stop doing this, we actually save memory.
My suspicion is that we use setter names transiently.
And removing a field itself save some memory.
Before:
flutter_elements
reachableObjects
count: 11865740
change: -0.01% -1335
size: 993783127 = 970491 KB = 947.7 MB
change: -0.01% -72336 = -70 KB
After:
flutter_elements
reachableObjects
count: 11861762
change: -0.04% -5313
size: 987428847 = 964285 KB = 941.7 MB
change: -0.65% -6426616 = -6275 KB = -6.1 MB
Change-Id: Iaab513e545862df53ae1f144a7a8b1e695768d06
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386261
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Fixes https://github.com/dart-lang/linter/issues/3814
This CL ends up solving a few problems, all rooted to one issue: binary
expressions were considered as they live in the syntax tree, but as they
are read by a human, they can be longer chains of additions.
1. We reported `'' + '' + ''` even though adding two string literals is
considered OK. This is because the outer binary expression has
`'' + ''` as its left operand, which isn't technically a string
literal. This over-reporting is corrected.
2. Binary expressions inside string interpolations were not considered.
This corrects that.
3. We can now report correctly the two issues in code like
`x + '' + '' + x`.
Change-Id: If2a6fdf11d815d42d732cf2713b9e6dea3932e3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385320
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Adds additional members to accept or return elements from the new model
that will be necessary for the migration.
Also overrides `Element.name` in places where the name can't be `null`.
Change-Id: Id933afc423c891bf94c0528a41363f57c883bc66
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386100
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
In many cases `element:` property is not very interesting, and we
should replace it with checking cross-linking between elements and
fragments.
I kept `element:` for now as a demonstration.
However there are also useful additions, see: superConstructor: <testLibraryFragment>::@class::A::@constructor::new#element
in class_test.dart
Change-Id: I1ad16ddcf73be6af81da92f1d831d5b165629860
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385362
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
There will undoubtedly be other places where we need hooks, but I thought
that these would provide a good starting point for attempts to start
converting existing code to the new API.
Change-Id: If04aea4244efaca5a81553fbd88066b24c169290
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385303
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
When determining whether a switch statement is exhaustive, it's
important for the exhaustiveness algorithm to ignore cases containing
`when` clauses, since a `when` clause creates the possiblity that the
case won't match.
Previously, the way this was done in the analyzer was for the
`SpaceCreator.createRootSpace` method to create an unknown space for
cases containing `when` clauses. This approach produced the correct
behavior when determining whether the switch statement as a whole was
exhaustive, but since it discarded information about the pattern being
matched, it limited the ability to determine whether an individual
case was reachable, leading to
https://github.com/dart-lang/sdk/issues/56710.
To fix this, `SpaceCreator.createRootSpace` is changed so that it
always produces a space that describes the case pattern, regardless of
whether a `when` clause is present, and instead,
`computeExhaustiveness` is responsible for ensuring that the case is
properly excluded from the determination of whether the switch is
exhaustive. This allows `computeExhaustiveness` to properly computate
whether each individual case is reachable, even for cases that have
`when` clauses.
This change in approach produced some minor differences in the test
cases in `pkg/_fe_analyzer_shared/test/exhaustiveness/data`, but these
differences are not user-observable.
Fixes https://github.com/dart-lang/sdk/issues/56710.
Change-Id: I36629a77c4c1832fb1b8abb6ea7b109e0ca14373
Bug: https://github.com/dart-lang/sdk/issues/56710
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384326
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
- Rename resource identifiers in the VM to usage recordings.
- Use package:record_use for serialization.
- Rename and use the experimental flag for this feature.
- Recognize tear-offs and top-level methods as well.
Next steps:
- Add constant instance recording.
- Expose API in package:native_assets_cli's link callback.
TEST=pkg/vm/test/transformations/record_use_test.dart
Change-Id: I8af3625165f78925ae943711245af93a239d1012
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383040
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Moritz Sümmermann <mosum@google.com>
This does a couple of things:
- Overrides `Fragment.element` consistently (and removes unnecessary
casts)
- Adds the `element` for each fragment to the dump
- Implements support for field-formal and super-formal parameters and
adds constructor parameters to the dump
Change-Id: Ie30806912842e3243e7bdc5e84ec7a11cb623751
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384860
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This warning is similar to the existing `UNREACHABLE_SWITCH_CASE`
warning, except that it warns if the `default` clause of a switch
statement is unreachable due to all the `case` clasuses fully
exhausting the switched type.
To make the implementation easier, I changed the API for the
`reportExhaustiveness` method in `_fe_analyzer_shared` (which is the
primary entry point to the shared exhaustiveness checker). Previously,
this method returned a list of `ExhaustivenessError`, where each list
element was either an `UnreachableCaseError` (indicating that a
certain case was unreachable) or a `NonExhaustiveError` (indicating
that the entire switch statement was not exhaustive). If the caller
passed in `false` for `computeUnreachable`, `UnreachableCaseError`s
would not be returned, so the returned list would either be empty or
contain a single `NonExhaustiveError`.
The new API renames the types for clarity:
- `NonExhaustiveError` becomes `NonExhaustiveness`, to highlight the
fact that it's not necessarily an error for the switch's cases to be
non-exhaustive; it's only an error if the scrutinee's static type is
an "always exhaustive" type and there is no `default` clause.
- `UnreachableCaseError` becomes `CaseUnreachability`, to highlight
the fact that it's not an error for a case to be unreachable; it's a
warning.
Also, the new API adds instances of `CaseUnreachability` to an
optional user-provided list instead of returning a newly created list;
this allows callers to communicate that they don't need to see
`CaseUnreachability` information by passing `null`. This frees up the
return type to simply be an instance of `NonExhaustiveness` (if the
cases are not exhaustive) or `null` (if they are exhaustive). This
makes it easier for the analyzer to decide whether to issue the new
warning, because it doesn't have to dig around the list looking for an
instance of `NonExhaustiveness`.
The new warning has an associated quick fix (remove the unreachable
`default` clause). This quick fix uses the same `RemoveDeadCode` logic
in the analysis server that the existing `UNREACHABLE_SWITCH_CASE`
warning uses.
Fixes https://github.com/dart-lang/sdk/issues/54575.
Bug: https://github.com/dart-lang/sdk/issues/54575
Change-Id: I18b6b7c5249d77d28ead7488b4aae4ea65c4b664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/378960
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Graciliano Monteiro Passos