Chromium

Looking through the examples given in the broader bug, I see a two samples that I expected to be fixed but are not:

let result = Promise.reject(null); // no action yet
result.catch(() => {}); // empty catch handler

  var rjp = new Promise(function (rs, rj) {
    rj(null);
    //setTimeout(rj, 0)
  });
  rjp.catch(function (err) {});

Need to investigate if these are similar enough in bytecode that the heuristic should be expanded to cover them.

In fact these two examples will pause if copied into the console but if you put them in a function they work. When evaluated at the top level the relevant interpreter bytecodes are:

   21 E> 0x369c000401e9 @   21 : 61 f7 f6 f5 04    CallProperty1 r2, r3, r4, [4]
   13 E> 0x369c000401ee @   26 : 25 02             StaCurrentContextSlot [2]
   40 S> 0x369c000401f0 @   28 : 17 02             LdaImmutableCurrentContextSlot [2]
         0x369c000401f2 @   30 : c7                Star3
   47 E> 0x369c000401f3 @   31 : 2f f6 04 06       GetNamedProperty r3, [4], [6]

The first CallProperty1 is the call to Promise.reject() and the GetNamedProperty is the lookup for .catch. Normally we see call, star, GetNamedProperty in immediate sequence, but in the top-level case we save to the context first, then reload it and save to a register.

We could add support for this case, but I'm not convinced it is necessary. Code typed into the console isn't the case we need to optimize around. I can get the same behavior by capturing the promise in a closure, but it's not clear what the correct behavior should be in that case, as if the original promise (as opposed to the one returned from .catch) is saved, it might also be awaited or .thenned, and then the exception will be reported to the console as uncaught. So it's reasonable to be wary of this code pattern, though it wouldn't be hard to add support for it if it is the subject of user feedback.

I'm still considering this bug fixed.

I suspect this has nothing to do with the REPL per se, but a similar thing would happen if you add a with scope to your function, so I do believe this needs to be handled as well.