This CL:
* Adds a benchmark of running `dart analyze` on a single small file.
* Adds a benchmark of running `dart analyze` on a single project.
* Adds a benchmark of running `dart analyze` on several projects.
* Adds a hidden flag to `dart analyze` so it reports ram usage:
run via `dart analyze --format=json --memory` and the memory
usage will be reported in the json output.
All the bencmarks run without and with cache for speed testing, and
without and with cache when measuring memory usage.
The idea of running this via `dart analyze` instead of running either
the script or the snapshot is to measure the "real world" speed which
could be different (although in practise it _does_ just run the
snapshot).
Future CL(s) should also add benchmarks for queries using the
language server.
Change-Id: Iad6d6d72c1a2ed18ab51d056b4914f8b6eb963e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/276100
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Implement the necessary flow analysis bookkeeping so that in a pattern
of the form `P1 && P2`, any type checks performed by `P1` will be
reflected in the matched value type used by `P2`. To accomplish this,
we allocate a promotion key to represent the "cached value" matched by
every pattern and subpattern (so that `P1 && P2` promotes properly
even when in a subpattern of another pattern). This promotion key is
stored (in the form of a `ReferenceWithType<Type>`) in the
`_PatternContext` class.
Also, move `_scrutineeReference` and `_scrutineeType` into
`_FlowAnalysisImpl`; this preserves the existing behaviour of
promoting the scrutinee expression, but with less bookkeeping (since
we don't need to pass it along from one context to the next). And add
`_FlowAnalysisImpl._scrutineeSsaReference` so that if the scrutinee is
modified during execution of the switch statement, it won't be
erroneously promoted by patterns that follow.
Finally, implement some preliminary logic for `||` patterns to avoid
breaking existing tests. I will fill this out (and test it
thoroughly) in a follow-up CL.
Bug: https://github.com/dart-lang/sdk/issues/50419
Change-Id: I0d934e706ad5b19cda46a198afb2fb7a4309829b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275788
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
It is being removed in Dart 3.0 and a `TypeError` should be used
instead. This is true in legacy code as well and all test
expectations will be updated.
Change-Id: I021fa4ecb1a9bbc404598113c65349e17926cd91
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275782
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This deprecated class cannot be removed just yet because
we still need to throw something in case of cyclic initialization
in Dart legacy libraries (which are still supported).
Class CyclicInitializationError is copied for each implementation
(VM, dart2js and DDC) and made private. Each implementation now has
an independent private class which can be removed separately.
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/49529
Change-Id: I8100bbe16636c12c4cbabbb5fe770f4c648c4249
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275120
Commit-Queue: Michael Thomsen <mit@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Migration tool currently crashes if a class overrides
some methods it got by adding a mixin.
Added a test for that and fixed the crash, the fix
boils down to casting to just `InterfaceElement` instead
of `ClassElement`.
Tested: added a new test
Change-Id: Iab5ddb26c4930ed2020d6f3caa0710e55f24d8c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275721
Commit-Queue: Ilya Yanok <yanok@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Language specification (section 17.2) says two strings are identical
when they're both constants and equal.
It doesn't mention adjacent strings, but looking at the tests, it seems
like juxtaposition of constant strings are expected to be constants as
well.
This adds a special case in string juxtaposition compiler to handle the
case where parts of the adjacent strings are all constants.
New passing tests:
- co19/Language/Expressions/Instance_Creation/Const/canonicalized_t05
- co19/Language/Expressions/Strings/adjacent_strings_t02
- language/const/string_test
Change-Id: Ib46582be492ba20c417546cbfb4e67b2d90e3ba3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275200
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Now that 9df6656aa9 has appropriately propagated and the build rules in
google3 have been updated, re-add checks to ensure that the empty
section used to pad the original header exists and that the new header
is smaller than the old header.
Bug: https://github.com/dart-lang/sdk/issues/49783
Change-Id: I5b8b31bf9edf4814686eb7928457a9a7d53c0727
Cq-Include-Trybots: luci.dart.try:dart-sdk-mac-try,dart-sdk-mac-arm64-try,pkg-mac-release-arm64-try,pkg-mac-release-try,vm-kernel-mac-release-arm64-try,vm-kernel-mac-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275622
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Previously, the client had to know that the relational operator should
be looked up in the matched value type. Now the shared analysis logic
requests the lookup and supplies the appropriate type.
It's a small change, and one might argue that it doesn't really move
around very much business logic, but it makes the tests more readable
so I think it's worth it.
Change-Id: I936d5f5f929f11800efe25974334c898c7e1072d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275360
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This enables the front end to skip the old-style (enum-based)
exhaustiveness checking algorithm when pattern support is enabled,
because with pattern support enabled, switches on enums are required
to be exhaustive (this will be checked by the new exhaustiveness
checking algorithm).
That in turn means that in the future, when we remove support for
language versions that lack patterns support, we will be able to
remove the old-style exhaustiveness checking algorithm.
This change has a small effect on code generated by the WASM back-end
(the only back-end that uses `isExplicitlyExhaustive`): for a switch
statement that is exhaustive *and* has an unreachable `default`
clause, after testing all the cases, the WASM back-end will generate a
branch to the `default` case. Previously it would instead generate an
`unreachable` instruction. There should be no behavioural difference
because the instruction in question is unreachable in both cases.
Also, there should be negligible code size difference because the body
of the `default` case is being emitted either way.
Bug: https://github.com/dart-lang/sdk/issues/50419
Change-Id: Id6bd7d9a540cb1b4d9c3624db8ff494438276bea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274924
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
A desired feature for flow analysis of patterns is that the matched
value type of one subpattern may depend on promotions from previous
patterns. For example, we want this to work:
int? x = ...;
if (x case null || < 0) ...;
This means that although the type of the scrutinee is `int?`, after
the subpattern `null` has been processed, type promotion should
promote the matched value type to `int`, so that the subpattern `< 0`
doesn't report an error.
This requires changing the API of the shared patterns analysis logic,
so that the client is no longer responsible for passing around the
matched value type. Instead, flow analysis keeps track of it and
provides it to the client when requested.
In follow-up CLs I'll add the necessary logic to flow analysis to
actually promote the matched value type in situations like the example
above.
Change-Id: I6ce66962af32f9bd93bfe4082ba256de627d3cc6
Bug: https://github.com/dart-lang/sdk/issues/50419
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274942
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This updates the exhaustiveness implementation to have specific static
built-in types for nullableObject (the top) and its underlying nonNullableObject,
nullType and its underlying neverType. In the previous encoding, the top
wasn't nullable (if you queried the isNullable property) but was still
assumed to contain `Null` in other parts of the code.
With this change, the top space is now an ExtractSpace based on
StaticType.nullableObject, the empty space is an ExtractSpace based on
StaticType.neverType and record spaces are based on
StaticType.nonNullableObject.
The StaticType is now split into a StaticType interface and a
StaticTypeImpl implementation class for the non-built-in types. This
prepares for integrating the exhaustiveness checking with the analyzer
and CFE where the properties of the sub/supertype relation and fields of
the StaticType needs to be computed lazily.
Change-Id: I5a6919d7cba356f9bc8ac3f69fd3ac2b41319e9b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274020
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
These are scattered changes to get to type inferrence.
- Add some impact tracking for used record types
- Add RecordTypeInformation and FieldInRecordTypeInformation
- Add a simple test to show inference is currently very conservative.
Change-Id: Icb81033b11588c1bddd01c8c5fcf69950fdb77e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275161
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Johnni Winther