Scopes: What is the correct position of generated ranges for call sites.

[rakudrama]

What are rules for placing ranges for generated call sites and generated code for inlined methods so that they are correct for all major JavaScript engines?

Can two different stacks be encoded at one generated position?

Expanding on #40 (comment):

     1	class Foo {
     2	  int value = 10;
     3	  
     4	  Foo check(Foo? x) {
     5	    return x!;
     6	  }
     7	
     8	  @pragma('dart2js:never-inline')
     9	  void run(Foo? x, Foo? y) {
    10	    work(check(x), y);
    11	  }
    12	
    13	  void work(Foo x, Foo? y) {
    14	    x.speak(y);
    15	  }
    16	
    17	  @pragma('dart2js:never-inline')
    18	  void speak(Foo? z) {
    19	    print('Foo(${z!.value})');
    20	  }
    21	
    22	  void demo1() {
    23	    run(null, this);
    24	  }
    25	
    26	  void demo2() {
    27	    final a = Foo();
    28	    a.value += 90;
    29	    run(a, null);
    30	  }
    31	}
    32	
    33	@pragma('dart2js:disable-inlining')
    34	main() {
    35	  print('---- 1');
    36	  try {
    37	    Foo().demo1();
    38	  } catch (e, s) {
    39	    print('$e\n$s');
    40	  }
    41	  print('---- 2');
    42	  try {
    43	    Foo().demo2();
    44	  } catch (e, s) {
    45	    print('$e\n$s');
    46	  }
    47	}

The Dart VM prints the following stacks.
This is the desired translation for the JavaScript stacks.

---- 1
Null check operator used on a null value
#0      Foo.check (file:///tmp/sm.dart:5:13)
#1      Foo.run (file:///tmp/sm.dart:10:10)
#2      Foo.demo1 (file:///tmp/sm.dart:23:5)
#3      main (file:///tmp/sm.dart:37:11)

---- 2
Null check operator used on a null value
#0      Foo.speak (file:///tmp/sm.dart:19:19)
#1      Foo.work (file:///tmp/sm.dart:14:7)
#2      Foo.run (file:///tmp/sm.dart:10:5)
#3      Foo.demo2 (file:///tmp/sm.dart:29:5)
#4      main (file:///tmp/sm.dart:43:11)

The code compiled by dart2js and run on V8 prints the following:

---- 1
Null check operator used on a null value
TypeError: Cannot read properties of null (reading 'speak$1')
    at Foo.run$2 (sm.js:2809:9)
    at Foo.demo1$0 (sm.js:2815:12)
    at main (sm.js:2401:18)
---- 2
Null check operator used on a null value
TypeError: Cannot read properties of null (reading 'value')
    at Foo.speak$1 (sm.js:2812:26)
    at Foo.run$2 (sm.js:2809:9)
    at Foo.demo2$0 (sm.js:2820:12)
    at main (sm.js:2409:18)

Foo.run$2 (sm.js:2809:9) appears in both V8 stacks.
Under ---- 1 this stack frame should be translated to an inlined call to check:

#0      Foo.check (file:///tmp/sm.dart:5:13)
#1      Foo.run (file:///tmp/sm.dart:10:10)

Under ---- 2, the identical stack frame line should be translated to an inlined call to work:

#1      Foo.work (file:///tmp/sm.dart:14:7)
#2      Foo.run (file:///tmp/sm.dart:10:5)

What is happening is that dart2js sometimes combines a null check and an subsequent property read, since in JavaScript a property read from null or undefined fails, so can be considered to be and implicit null check. Inlining check and work into run brings the null check adjacent to the method call, allowing them to be combined:

  2807	  A.Foo.prototype = {
  2808	    run$2(x, y) {
  2809	      x.speak$1(y);
    //	12345678901234567890123456789
                ^
  2810	    },
  2811	    speak$1(z) {
  2812	      A.print("Foo(" + z.value + ")");
  2813	    },
  2814	    demo1$0() {
  2815	      this.run$2(null, this);
  2816	    },
  2817	    demo2$0() {
  2818	      var a = new A.Foo();
  2819	      a.value = 100;
  2820	      this.run$2(a, null);
  2821	    }
  2822	  };

The other JavaScript engines pick different locations:

JSC uses the positions 8 and 16 of the operators . and (.

---- 1
Null check operator used on a null value
run$2@sm.js:2809:8
demo1$0@sm.js:2815:17
main@sm.js:2401:25
---- 2
Null check operator used on a null value
speak$1@sm.js:2812:25
run$2@sm.js:2809:16
demo2$0@sm.js:2820:17
main@sm.js:2409:25

SM uses the position 7 and 9 of the identifiers x and speak$1.

---- 1
Null check operator used on a null value
run$2@sm.js:2809:7
demo1$0@sm.js:2815:12
main@sm.js:2401:18
---- 2
Null check operator used on a null value
speak$1@sm.js:2812:24
run$2@sm.js:2809:9
demo2$0@sm.js:2820:12
main@sm.js:2409:18

Two ranges, c for inlined check and w for inlined work would give a sensible result for JSC and SM

    x.speak$1(y);
    ccwwwwwwww--

For V8, the error in check shows as a wrong location inside work. This is confusing, since the binding for (work)x would show null for a non-nullable original source type.

[szuend]

I haven't worked through the example in detail but superficially this is not about where to put the "generated range" and more about where engines put source locations for calls in Error.stack. Error.stack is notoriously under-specified. Moreover, ECMA426 is unfortunately not in the position to spec this.

If we'd wanted to align engine on Error.stack stack traces, we'd have to go through TC39 proper and spec it in ECMA262.

The most that TG4 can prescribe is:

• Where to put (named) mapping points w.r.t. the ECMA262 AST
• Where to put generated range start/end w.r.t. the ECMA262 AST

The fact that the . in x.speak$1(y); will be the source location of both the implicit undefined check as well as the speak$1 call is not something we can disambiguate in the "scopes" proposal easily and I don't think we should. The sheer number constellations to account for all the ambiguity across all the engines and what we'd have to do to solve it, is IMHO not feasible.

At the moment, the scopes proposal allows a simple translation of "generated location" -> "(inlined) stack frame(s)". No additional information is needed. Given a generated position, you can expand any inlined stack frames at that location and get the original function names for it.

To solve the above problem, we'd have to add conditions to that, and I'm not sure we can stick to a couple simple ones. E.g. in this case it might depend whether the "generated location" is at the top of the stack, or if it's not. In other cases it might depend on whether some specific function was called directly before/after or even if a certain location of another function is on the stack before/after.

I think we can keep this use-case in mind long-term, but we need to get a version of "scopes" out of the door that solves 80%-90% of the use-cases.