debugger: refactor internal/inspector/_inspect to use more primordials

[aduh95]

This is a refactoring of the module to use async/await where it makes more sense, and some other changes to enable ESLint on the file.

The no-restricted-syntax rule is still disabled as the inspector throws custom errors (which we might want to include in internal/errors at some point), and the linter doesn't know promise versions of setTimeout/setInterval.

[jasnell]

Should this go ahead and use return await Promise so that any possible error stack would include the runScript frame?

[aduh95]

I'm not sure I follow, isn't await <promise> and return <promise> similar when it's the last expression on an async function?

[jasnell]

Yes and no. With return <promise> if <promise> rejects, the error stack trace will not include the wrapping async function (in this case runScript). However, when using return await <promise> the error stack will contain runScript.

[aduh95]

Am I doing this wrong? It seems the stack trace does contain the wrapping function in the dummy test cases I've came up with..

Also with node:

$ node -e '(async function runScripts(){return new Promise((_,r)=>{r(new Error)})})()'
[eval]:1
(async function runScripts(){return new Promise((_,r)=>{r(new Error)})})()
                                                          ^

Error
    at [eval]:1:59
    at new Promise (<anonymous>)
    at runScripts ([eval]:1:37)
    at [eval]:1:73
    at Script.runInThisContext (node:vm:131:12)
    at Object.runInThisContext (node:vm:308:38)
    at node:internal/process/execution:81:19
    at [eval]-wrapper:6:22
    at evalScript (node:internal/process/execution:80:60)
    at node:internal/main/eval_string:27:3
$ node -e '(async function runScripts(){return new Promise(()=>{throw new Error})})()' 
[eval]:1
(async function runScripts(){return new Promise(()=>{throw new Error})})()
                                                           ^

Error
    at [eval]:1:60
    at new Promise (<anonymous>)
    at runScripts ([eval]:1:37)
    at [eval]:1:73
    at Script.runInThisContext (node:vm:131:12)
    at Object.runInThisContext (node:vm:308:38)
    at node:internal/process/execution:81:19
    at [eval]-wrapper:6:22
    at evalScript (node:internal/process/execution:80:60)
    at node:internal/main/eval_string:27:3

[jasnell]

Yeah looking at it again, in this particular case returning the Promise is ok Actually no, because of the await. Here's the case that I was talking about:

const { setTimeout } = require('timers/promises');

async function foo() {
  await setTimeout(100);
  return Promise.reject(new Error('boom'));
}

async function bar() {
  return foo();
}

// vs.

async function bar2() {
  return await foo();
}

Running bar() produces an error:

> Uncaught Error: boom
    at foo (REPL33:4:23)

While running bar2() produces an error:

> Uncaught Error: boom
    at foo (REPL33:4:23)
    at async bar2 (REPL41:2:8)

The key is the use of the await in foo... it separates everything that comes after it into a separate stack.

[aduh95]

Seems like a V8 bug, interesting. Unless you feel strongly about this, I'm tempted to leave it as is until a linter rule comes to enforce it.

[Trott]

Needs a rebase. If tests are passing, then 👍 from me.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/37879/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/37880/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/37881/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/37886/

[aduh95]

Landed in f331a18

[richardlau]

Re. backport-blocked-v14.x. This uses timers/promises which currently doesn't currently exist on Node.js 14. Promisified setInterval would need #37153, which is semver-minor.