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>
Async transformation uses dynamic variables in few places (e.g.
for temporaries and for incomming arguments) - which creates
not strongly typed AST with method invocations having dynamic
receivers and non-null interface targets at the same time.
To maintain strong typedness of the AST we insert unsafeCast
when accessing the temporaries.
Bug: https://github.com/dart-lang/sdk/issues/34463
Change-Id: I11e38c128645ebc8acb0c982a80fe4c5c4036673
Reviewed-on: https://dart-review.googlesource.com/75000
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>