This brings it in sync with the existing implementation in Cider.
In Cider we cannot enfore no-putGet-when-data-exists because of possible
race condition, when data did not exist during `get` by isolate1, but
was put shortly after by isolate2, before isolate1 computed data and
attempted to `putGet`.
Change-Id: I36d9083f204be48e529e675a3f046784375f6fbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284580
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
It looks like the error is currently truncated after the 100 root children and
approximately 170 reader URIs. Trimming to 50 root children and 50 reader URIs
seems quite safe. I can't claim that I foresee situations that could only be
solved by seeing the 50th URI, but I don't see any reason to pick a smaller
number.
Bug: b/267353400
Change-Id: I12ddcd7c89cfdc95faaef9feab56b6c22eee459f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284281
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jaime Wren <jwren@google.com>
This reverts commit 0c05e33836.
Reason for revert: breaks ~10% of G3 smoke suite.
Original change's description:
> Enforce current library restrictions.
>
> Mark all currently unimplementable types as `final`, or `sealed` for `num` and `final` for `Function`.
> Mark all current classes intended as mixins as `mixin class`.
>
> More additions and cleanup will follow,
> but this change should make everything keep working as today
> if we flip the switch.
>
> TEST= No new tests, very little actual change, covered by existing tests with few changes. Will add more tests when adding more modifiers.
>
> Change-Id: I40e724f823e7f88cdef186d2f73874df256e2f43
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281683
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
> Reviewed-by: Aske Simon Christensen <askesc@google.com>
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Kallen Tu <kallentu@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Ib0cb5b7ec1a8c392bbf9bf4af8dc3efc0b27991d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284187
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Ilya Yanok <yanok@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Mark all currently unimplementable types as `final`, or `sealed` for `num` and `final` for `Function`.
Mark all current classes intended as mixins as `mixin class`.
More additions and cleanup will follow,
but this change should make everything keep working as today
if we flip the switch.
TEST= No new tests, very little actual change, covered by existing tests with few changes. Will add more tests when adding more modifiers.
Change-Id: I40e724f823e7f88cdef186d2f73874df256e2f43
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281683
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
This adds support for record types in the exhaustiveness algorithm.
The original algorithm was based on that record pattern would
match fields on all types, but that is no longer the case. Instead
record patterns only match corresponding to their own type. For this
reason the testing code is updated to create record spaces in relation
to a type. For instance, when the test create a record space {x: B}, it
is know create in relation to a type, say (x: A, y: A), and the create
space will therefore have (x: *, y: *) structure where the y: component
is implicitly Top, similar to how object patterns are used.
Unlike the Dart record types used for type checking and inference, the
record types used for exhaustiveness do not take the field types into
account for its subtype relation. This is avoid conclusions like
(int i, Object o) and (Object o, int i) having no values in common because
their corresponding types (int, Object) and (Object, int) are not subtypes
of each other. Instead, the subtype relation for record types used for
exhaustiveness only use the structure of the record to determine whether
two types are related.
Note though, that fields of a record type still know the type of the field.
This is used when expanded a record type into a space; the field spaces
will be derived from the field types in this case.
Change-Id: I84735d827494bcf384fd5f419d71933830ff5d15
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283182
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This optional error fires if patterns are enabled and the type
analyzer encounters a switch that is required to be exhaustive (i.e. a
switch expression, or a switch statement with an always-exhaustive
type), and flow analysis cannot prove that the switch is exhaustive.
This is intended to be available as a temporary workaround if we
decide to ship an early beta of the "patterns" feature before
exhaustiveness checking is sufficiently ready. We won't enable it
unless we need to, and we won't ship the final patterns feature with
it enabled.
Change-Id: I8c4c65c21abdc32b91537b3f30e7fd86f446f571
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283060
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This makes the unit tests clearer, since it's possible to tell the
meaning of each argument. It also simplifies the underlying unit
testing logic that formats the errors.
Change-Id: I7212fe0c909ca0b627f8a8889621af3a62a63f00
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283132
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This allows the parser to parse constant patterns at lower precedence
level in order to recognize more expressions in this context. To
support this, _parsePrecedenceExpressionLoop special cases a few cases
that should _not_ be parsed as expression in a constant pattern context.
Closes#50996
Change-Id: I43bb0ce52d366bd2dfcf47e12eec5883402f668a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/282100
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
The `numMergedCases` argument was a holdover from the old analyzer
representation of switch statements (in which cases sharing a body
were not merged); it is no longer useful.
Also, the analyzer tests in `switch_case_completes_normally_test.dart`
have been adjusted so that they no longer expect this error to be
issued when pattern support is enabled; this is consistent with the
spec (which removes this error).
Change-Id: Ia22a35b7a94ee585e0614d85012ee80b9dbc12d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283125
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
AbstractDartSdk._getPath has some "phases" trying to determine a
"dart import uri" from a File.
One of these phases checks if the given file is inside a directory that
one of the known sdk platforms is inside, thus allowing us to construct
a uri from there.
For instance if we know that `/a/b/c/d/e.dart` is called
`dart:foo/e.dart` and we’re presented with `/a/b/c/d/f.dart` we’ll
figure out that it’s called `dart:foo/f.dart`.
The code for this is very simple, but very inefficient.
This CL makes it more efficient.
This is only applicable when analyzing with the flutter platform.
The below benchmarks show a ~7 to ~33% improvement depending on what's
being analyzed. It's all done via `dart analyze` where the first run
has been discarded so everything is in cache.
Running on `rwf-materials`:
```
Before:
real 1m54.491s
real 1m55.969s
real 1m53.802s
Now:
real 1m16.348s
real 1m17.570s
real 1m17.149s
Difference at 95.0% confidence
-37.7317 +/- 1.06819
-32.8805% +/- 0.930855%
(Student's t, pooled s = 0.471277)
```
Running on "flutter gallery":
```
Before:
real 0m2.836s
real 0m2.783s
real 0m2.718s
Now:
real 0m2.478s
real 0m2.492s
real 0m2.451s
Difference at 95.0% confidence
-0.305333 +/- 0.10044
-10.9872% +/- 3.61426%
(Student's t, pooled s = 0.0443133)
```
Running on "flutter-wonderous-app":
```
Before:
real 0m2.019s
real 0m1.999s
real 0m1.984s
Now:
real 0m1.863s
real 0m1.821s
real 0m1.856s
Difference at 95.0% confidence
-0.154 +/- 0.0457455
-7.69743% +/- 2.28652%
(Student's t, pooled s = 0.0201825)
```
Running on "flutter gallery" and "flutter-wonderous-app" at the same time:
```
Before:
real 0m3.446s
real 0m3.407s
real 0m3.431s
Now:
real 0m2.993s
real 0m2.965s
real 0m3.008s
Difference at 95.0% confidence
-0.439333 +/- 0.0470921
-12.816% +/- 1.37375%
(Student's t, pooled s = 0.0207766)
```
Change-Id: I13e81e96312d9cb5ad2a8244a0cb7722a49c4460
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/282280
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Specifically, we:
1. Extract separate 'body' operation in '_resolveForCompletion', so
that we separate the timing of this method execution vs the timing
how long it took to strat running this body.
2. Add `OperationPerformanceImpl performance` to `computeSuggestions`.
3. Remove 'DartCompletionManager-' prefix from completion operations.
Change-Id: I01986e06cb51167b7d5702a10f7512e04305298c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/282387
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Konstantin Shcheglov