"show source" is not always respected under lazy compilation

[robhogan]

Bug Description

Lazy compilation does not respect "show source", so [function].toString() fails to provide useful output.

This is observable under React Native, typically when loading a bundle in development, where we use lazy compilation for input JS exceeding 64KB. It makes "show source" quite unpredictable. Unknown whether other directives are similarly affected.

The symptoms have been reported before but not narrowed down to a lazy compilation issue:

• Hermes "show source" not working in debug mode. #763
• 'show source' does not work on first run when debugging #612
• Function toString does not behave the same with hermes turned on #114

Hermes git revision (if applicable): current / 579e82b
React Native version: N/A
OS: macOS / iOS
Platform: arm64

Steps To Reproduce with Hermes CLI

// show-source.js
print(
  (function getCode() {
    function someFunction() {
      'show source';
      return 'hi!';
    }
    return someFunction.toString();
  })(),
);

'show source' respected with eager compilation

./bin/hermes show-source.js
function someFunction() {
      'show source';
      return 'hi!';
    }

But fails with lazy compilation

./bin/hermes -lazy show-source.js
function someFunction() { [bytecode] }

The Expected Behavior

Lazy compilation doesn't change observable behaviour - show source should work both ways.

[avp]

This is due to a problem in how lazy compilation resolves the function sources table in main Hermes. It always tries to lookup on the root RuntimeModule, which is only valid if the function was declared at the top level (which is why our test lazy-function-toString.js passes).

In reality, we'd have to be able to look up the function source in the parent RuntimeModule. We don't currently store this information, so it'd require more than a trivial change to main Hermes to fix.

This does work in Static Hermes, because we've simplified the lazy compilation mechanism significantly and now all the tables are shared among all the compilation invocations.

[tmikov]

I am applying the label fixed-in-sh, meaning that this has been fixed in Static Hermes but is "Wontfix" in Hermes. We need this label because technically SH has not been released yet, but at the same time we don't want to keep issues like this open.