Host-specific hook for HostPromiseRejectionTracker

[rwaldron]

The conversation begins here: https://github.com/tc39/test262/pull/1156#issuecomment-318159020

cc @ljharb @littledan @benjamingr @leobalter @jugglinmike

[benjamingr]

I'd love it if @domenic weighed in here too since (I think) he knows the most about HostPromiseRejectionTracker. I would love to help with anything Node related or with general test cases.

[domenic]

I don't think this can usefully be tested in test262, because the host's implementation could be to do nothing, in a which case no tests are applicable. Similarly, it could be arbitrarily complicated, so some kind of generic framework doesn't make sense either.

Besides the above, Node and web-platform-tests already have extensive tests of their APIs here, and so I don't think it's a high priority for test262.

[benjamingr]

@domenic so you're saying this should be tested in Node and web-platform-tests? That makes sense.

Is there a formal (or not formal) process in the web-platform tests for ECMAScript removing/adding a feature? I'm not aware of anything of the sort for Node.

[littledan]

@domenic The reason this came up is because I was suggesting testing how Promise.prototype.finally interacts with this hook (since it does so in a slightly counterintuitive way). Do you think tests for these new JS language feature interactions should always be done in those embedder repositories?

[domenic]

Yes; everything related to host hooks should be tested in host test suites.

[ljharb]

@littledan i'm not sure how it's counterintuitive - in const y = x.finally(), x is "handled" by .finally which provides a catch handler, and y is unhandled if rejected just like x was prior to that line.

I agree that host hooks should probably be tested in host tests, since there's no way to test them in the language semantics.

[littledan]

@domenic So should we not have detached TypedArray tests in test262?

[domenic]

Detached typed arrays are not specified in terms of an arbitrary-behavior host hook.