This renames InlineClass to ExtensionTypeDeclaration, and InlineType
to ExtensionType. Members of extension type declarations are called
extension type members instead of extension type declaration members
for "brevity".
TEST=existing
Change-Id: I91ed62533ddd345644492f04dc3310d007460288
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316780
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Before this CL kernel tags had specialized tags that was marked by the
single high bit, then using the three lowest bits for a value:
128 + value = 0b10000xxx
136 + value = 0b10001xxx
144 + value = 0b10010xxx
So the numbers from 128 to 151 is taken by this scheme, but because of
the high bit marking stuff being special we can't really use 152-256.
This CL shifts the specialized tags up so it instead uses the 3 highest
bits as a marker while still using the lower 3 bits for the value:
224 + value = 0b11100xxx
232 + value = 0b11101xxx
240 + value = 0b11110xxx
This takes up 224-247 and leave 248-255 unused. It would let us use
128-223 though.
(If we eventually need more we can probably remove one of the
specialized ranges (SpecializedVariableSet isn't used very much in
previously sampled dill files) and use 4 bits for tagging).
Additionally, a tool to print free tags has been added (via binary.md),
and the "binary version is in sync with VM" test has been prepared
for version > 99.
TEST=Existing tests.
Change-Id: If77b12cee6fc3801628dd67dc40afbb018ec8a61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/284302
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
I've sampled (eagerly) reading the VM platform, a compilation of
dart2js, a compilation of "flutter gallery" and a compilation of a big
internal app, and reordered switch cases accordingly.
I can't measure any difference in runtime, but have a hard time
thinking it's not better.
I've included the tool that does the sampling.
Change-Id: If61c5a95265229c238020264010553f281fec49c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/267362
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This changes tool/fasta.dart to run the subcommand in the same VM when
no VM arguments are specified. This speeds up the tool and as a
consequence speeds up the tool/update_all.dart and
tool/update_expectation.dart tools.
Change-Id: I80b61a692a3ac2e15a7d1d097e65e1efbf9e4aee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/236560
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This CL adds a tool that can compare the class hierarchies of two dill files.
Currently it only checks for public classes and their public supertypes.
We could extend the tool later if needed.
Currently it gives this for flutter:
```
$ out/ReleaseX64/dart pkg/kernel/bin/compare_hierarchies.dart /path/to/flutter/bin/cache/flutter_web_sdk/kernel/flutter_ddc_sdk_sound.dill /path/to/flutter/bin/cache/artifacts/engine/common/flutter_patched_sdk/platform_strong.dill "dart:nativewrappers#NativeFieldWrapperClass1"
(1): /path/to/flutter/bin/cache/flutter_web_sdk/kernel/flutter_ddc_sdk_sound.dill
(2): /path/to/flutter/bin/cache/artifacts/engine/common/flutter_patched_sdk/platform_strong.dill
Missing classes in lib dart:_internal
In (2) but not in (1): [VMLibraryHooks, Lists, VMInternalsForTesting, ClassID]
Missing classes in lib dart:ui
In (1) but not in (2): [PlatformViewRegistry]
Class(ColorFilter) in dart.ui from (2) has these extra supertypes: [ImageFilter (dart:ui)]
```
where the last line is https://github.com/dart-lang/sdk/issues/48245
It gives this for the dart sdk:
```
$ out/ReleaseX64/dart pkg/kernel/bin/compare_hierarchies.dart out/ReleaseX64/vm_platform_strong.dill out/ReleaseX64/ddc_platform_sound.dill "dart:nativewrappers#NativeFieldWrapperClass1"
(1): out/ReleaseX64/vm_platform_strong.dill
(2): out/ReleaseX64/ddc_platform_sound.dill
Missing classes in lib dart:_internal
In (1) but not in (2): [VMLibraryHooks, Lists, VMInternalsForTesting, ClassID]
```
which seems fine (dart:_internal after all)
Change-Id: I03c0dbcc3e5058a0c7d6a996b511cf6d449dd4f3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231100
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Tool will try to extract useful information from invalid (e.g. partial
or wrong version) dill.
This is a first stab and could possibly be extended and improved in the
future.
Change-Id: Ib381794a3fe80036bb845800488fa0e1a7f04f83
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211241
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When we perform constant evaluation in the CFE, the async transform
runs after constant evaluation. Thus, it can no longer use const
bool.fromEnvironment("dart.vm.product") to query whether the VM is
in product mode.
Instead, it can read the product mode define directly from the
environment defines given to the CFE and generate different code
depending on the value.
Change-Id: I2aabc4a84b50a940d35d5664ff4ebdf0680ed5c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111645
Reviewed-by: Johnni Winther <johnniwinther@google.com>
TBR=askesc@google.com
Revert "[CFE] Move constant evaluator to Fasta."
This reverts commit 845b5b2df1.
Revert "[CFE] Always call the constant evaluator by the evaluate method."
This reverts commit 91bc4ec2b9.
Revert "[CFE] Use Fasta diagnostics in the constant evaluator."
This reverts commit c7b572aa29.
Revert "[CFE] Check for null in constant evaluation"
This reverts commit e6d2751e9c.
Revert "Rename import after moving file."
This reverts commit a6e2c5eb4c.
Change-Id: Iadfe087c0110f6f331b82d990213f95d3ef4541b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97223
Reviewed-by: William Hesse <whesse@google.com>
This is in preparation for recognizing Fasta-specific nodes in the
constant evaluator, and for using the Fasta diagnostics framework.
Change-Id: I8535fbb68e622f1814a1d577c348d87e573b6b34
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96081
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Make the constant evaluator take an explicit error reporter so we have
to opt in to using the "simple" one that reports errors in an ad hoc
way. This is the start of a change to use Fasta-controlled error
messages throughout and eventually get rid of the simple error
handler, and to continue constant evaluation after the first constant
error.
Change-Id: If6b1801edab6063754b642cf4a603abf9d63103a
Reviewed-on: https://dart-review.googlesource.com/c/89501
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Auto-Submit: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This flag was always true so we can remove it and specialize the
remaining code that used it. The only code that used it was in the
Dart VM's async transformation.
Specializing that code led to some unused fields in the async helper
class which were removed. This triggered me to look at core types
which seems to have a lot of unused stuff.
Change-Id: I7da800ca17ac05478149f4c90337a38d2c2b1459
Reviewed-on: https://dart-review.googlesource.com/c/87960
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
* Ensure that we have a .dill file and it has the correct version before
we start decoding it in dump.dart.
* Throw errors, not strings. Ensure that they have a useful
toString().
* Do not print usage except when the command is invoked
incorrectly (wrong number of arguments). Once we get into the
command it's less likely that it's been invoked incorrectly and more
likely that something else has gone wrong.
Because these utilities are invoked from other scripts (like the
fasta command), printing their usage for problems other than
invoking them correctly doesn't match the way that they were invoked
and it's confusing.
Change-Id: I7832383594d2b3719a0a7a7392ba4685717a79d2
Reviewed-on: https://dart-review.googlesource.com/c/78206
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Johnni Winther