* 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>
This CL adds two new kernel tools which can answer questions about
a dill file:
* count_breakdown.dart
Enumerates the different node types in the provided dill file and
counts them.
This has proved useful in the past to e.g. see how many doubles are
included in Flutter.
* size_breakdown.dart
Gives an overview of which parts of the dill file contributes how many
bytes.
This has proved useful in the past to see that the string table gets
huge when we have many doubles (because we currently save doubles in
kernel as strings).
It also adds error handling and usage information to existing tools.
Change-Id: Ie2ce9e4b8806d5975dba8f57445705a840be3474
Reviewed-on: https://dart-review.googlesource.com/42660
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Kevin Millikin