util: support inspecting Map, Set, and Promise

[monsanto]

Among other things, this makes working with ES6 containers bearable on the REPL.

Before:

> new Map([[1, "foo"], [null, "bar"], [{quux: 42}, undefined]])
{}

After:

> new Map([[1, "foo"], [null, "bar"], [{quux: 42}, undefined]])
Map { 1 => 'foo', null => 'bar', { quux: 42 } => undefined }

The output format is inspired by Chrome DevTools.

I would like to support inspecting promises but I do not know of a way to synchronously obtain the status and fulfillment value. If someone would like to point me in the right direction I can provide a followup PR. (see below)

[domenic]

I would like to support inspecting promises but I do not know of a way to synchronously obtain the status and fulfillment value.

Probably only possible via the V8 API... would be worth looking at the dev tools code to see how it's done

[domenic]

Seems like this case needs tests

[brendanashworth]

style: semicolons here and below

[monsanto]

I have that in a new commit yet to be pushed. Is it normal that make jshint doesn't touch tests?

[brendanashworth]

Yeah, for some reason that choice was made a long time ago. Wouldn't call it "normal" though :)

[monsanto]

@domenic I have added a test covering the case you commented on, thanks.

There were no tests of alignment at all, so I took the luxury of adding tests for the rest of the containers as well.

[monsanto]

I just pushed a proof-of-concept implementation of util.inspect for Promises. It uses the mirror debugger to synchronously inspect Promises. (Alternatively, this could be done if I could have a module with compiler intrinsics enabled). There are bits I don't like about my implementation but I wanted to get this out there before I went to bed in case people think my course of action totally sucks and I should abandon ship 😛

Output looks like

> Promise.resolve(3)
Promise { 3 }
> Promise.reject(3)
Promise { <rejected> 3 }
> new Promise(function(){})
Promise { <pending> }

which is a change from Chrome DevTools, as they are ridiculously verbose:

> Promise.resolve(3)
Promise {[[PromiseStatus]]: "resolved", [[PromiseValue]]: 3}
> Promise.reject(3)
Promise {[[PromiseStatus]]: "rejected", [[PromiseValue]]: 3}
> new Promise(function(){})
Promise {[[PromiseStatus]]: "pending", [[PromiseValue]]: undefined}

[bnoordhuis]

Left some comments on the promise inspection code. I don't disagree with the Debug.MakeMirror approach (in fact I think it's the only way to crack open a promise) but I think the current implementation is creating mirrors too eagerly.

[monsanto]

@bnoordhuis Thank you for your comments.

runInDebugContext isn't cheap

I've hoisted it to the top of the file for simplicity; however if this is too expensive or otherwise unsatisfactory I can create it on demand and cache.

only way to crack open a promise

If we could have compiler intrinsics enabled for the lib/internals folder, the Promise internals are at the properties %CreateGlobalPrivateOwnSymbol("Promise#status") and ...("Promise#value"). I don't know if this is more or less desirable than using runInDebugContext. My guess is less, but perhaps this functionality would be useful for other things in the future..

Mirrors being cached

you are correct, I should have noticed this. They are now created as "transient" so they will not be cached.

creating so many mirrors

I've guarded the mirror creation with an instanceof, so the common case should not be penalized. The code still calls inspectPromise twice if it is indeed a native promise, but I can't eliminate this without a more involved refactor (or creating a closure, which seems just as bad as creating an extra mirror). I have tried to keep my changes as minimal as possible as this is my first io.js PR.

[chrisdickinson]

@domenic: Should we add support for Weak{Set,Map} inspection through Debug as a follow-on to this PR?

[domenic]

Noooo that seems very bad, basically exposes iteration to JS.

[chrisdickinson]

Yeah – I thought it might be a bit fraught with peril; was surprised to see the chrome dev tools expose that info.

[chrisdickinson]

The nits can probably be disregarded – just looked and saw that we were using map before, anyway :)

This LGTM. Unless @bnoordhuis or @domenic objects, I'll merge this tomorrow afternoon.

[bnoordhuis]

If we could have compiler intrinsics enabled for the lib/internals folder, the Promise internals are at the properties %CreateGlobalPrivateOwnSymbol("Promise#status") and ...("Promise#value").

It's possible to do that but it's kind of a hack:

const v8 = require('v8');
v8.setFlagsFromString('--allow_natives_syntax');
const promiseStatus = eval('%CreateGlobalPrivateOwnSymbol("Promise#status")');
const promiseValue = eval('%CreateGlobalPrivateOwnSymbol("Promise#value")');
v8.setFlagsFromString('--noallow_natives_syntax');

[bnoordhuis]

Preferably assign empty = false and use strict checks below (i.e. empty = empty === true && keys.length === 0 and if (empty === true) {.)

It's a minor thing but V8 emits marginally tighter code for strict boolean comparisons.

[monsanto]

@bnoordhuis @chrisdickinson OK, I addressed these style nits.

Just curious, is there a reason to keep the instanceof check out of inspectPromise?

It saves an instanceof check. I'm hoping to do a larger scale cleanup of util.inspect when I next have free time, which should fix the double inspectPromise calls and make this issue moot.

Aside: am I the only one who finds it moronic that recurseTimes is sometimes a number and sometimes not?

Yes, another thing I would like to clean up. (Or at least move the subtraction logic to a central place)

[chrisdickinson]

Merged in bf7ac08. Thanks!