Printing an object without an override of toString should show the instance type
class A { }
void main() => print(new A());
currently prints '[object Object]'
It should print something like [instance of A@453h3]
This still repros:
$ fletch debug ~/test.dart
Starting session. Type 'help' for a list of commands.
> r
[object Object]
### process terminated
$
@mkustermann can this be fixed with the symbol file or session connection as done in stack traces?
To be consistent with VM/dart2js, it should print Instance of 'A'.
This can be achieved by having Object.toString return "Instance of '${this.runtimeType}'" (if your Type objects have the same toString as other implementations.
Fletch doesn't have support for runtimeTypes. Additionally the fletch-vm doesn't have any knowledge about class/method names.
There are 3 scenarios to consider:
- running with a debugger attached: The vm has knowledge about class ids which can be decoded by the attached debugger, i.e.
class object -> class id -> class name - running from a snapshot in compact form: The vm has knowledge about class offsets in program space. These offsets can be used with an external program to decode the messages, i.e.
class object -> class offset -> class name - in all other scenarios (e.g. running a snapshot with
-Xunfold-program) there is no way to to go from class objects to names of classes
That's the status quo and this is also why it is a bit tricky.
I think we should start with the debugger case.
I think it would already be much more useful to print the class id as a number. Having that, you can already compare it to class ids of other objects.
So, after some discussion, we came to the conclusion to print something that is identifiable as a class id by some later tooling. So we could have
Instance of class::at::<offset>
Instance of class::id::<index>
where we know something and
Instance of class::ptr::<heap_address>
otherwise. The latter is not very helpful but normal production and development runs should never see this. An IDE should be able to find these in output and offer translation for them on demand.
This sounds like the right direction. What is the difference between at::
With just the Fletch CLI is there a way to dump a "symbol" table with the mapping in some cases?
How about:
fletch show symbols
And
fletch show symbol for id::42
?
The id used depends on the internal format of the program being run. If it is a compact snapshot, we can identify classes by their offset to the base of the program heap (at version). This is independent of where the snapshot was loaded and can be decoded by a tool.
If a debugger is attached, we have class ids to report. So we output the id version. Note that we do not have a reproducible offset to share in this scenario, so we cannot use the at version for both cases.
Lastly, if the program is not in the compact form and also not being debugged, we report the heap address of the class object. While that cannot be translated by any tool, it at least identifies a class uniquely so the ids can be compared within one run of the program.
@lukechurch I thought about a new command in the debugger (the id case) and then a tool that takes a snapshot and answers the above questions. If we use the fletch driver, it could try find a debugger session if the class id is of id type but for at ids it would need a snapshot or program.
Does the fletch driver ever do anything with snapshots?
Here is an implementation to emit the ids but it is so far lacking a test.
https://codereview.chromium.org/1510363003/