Patch to first-class function transformer

[NeilKleistGao]

A patch to #387.

• When calling a function defined in runtime.mls or globalThis, there is no need to throw an exception (due to the lack of symbol information), since we know calling such a function does not need to use the func.call form.
• When handling class Foo(x); new Foo(x), there is no need to check the path of the instantiation, since it is not a call. The term symbol of Foo.class has a kind syntax.Fun, which will break the transformation.
• Add missing symbols used in UCS
• Also check the disamb symbol to avoid transforming class construction unexpectedly

[LPTK]

• When calling a function defined in runtime.mls or globalThis, there is no need to throw an exception (due to the lack of symbol information), since we know calling such a function does not need to use the func.call form.

How do you know this? In the future, the runtime will also be compiled with lambda transformation, as that's how we'll compile to WASM. So ideally, we should have a proper solution to this problem. Don't we have the correct symbol, here?

[LPTK]

• The term symbol of Foo.class has a kind syntax.Fun, which will break the transformation.

Isn't that a bug? Foo.class is clearly not a function. Can we fix that instead?

[NeilKleistGao]

Don't we have the correct symbol, here?

No, we don't have symbols here.
e.g., runtime.Tuple.get is created by the following helper function

protected final def sel(p: Term, k: Ident): Term.SynthSel =
    (Term.SynthSel(p, k)(N, N): Term.SynthSel).resolve // the first `N` indicates the symbol

runtime.unreachable is generated by the following helper function:

lazy val unreachableFn =
    Select(Value.Ref(State.runtimeSymbol), Tree.Ident("unreachable"))(N)

[NeilKleistGao]

Isn't that a bug? Foo.class is clearly not a function. Can we fix that instead?

No. The actual case is: when writing new Foo(0), we are referring to the construction function, instead of the class definition

Foo1 = function Foo(x) {
  return globalThis.Object.freeze(new Foo.class(x));
};

and the .class suffix is generated by JSBuilder.scala. So it does have a kind syntax.Fun.

[LPTK]

No, we don't have symbols here.

The correct fix is to put the symbol there, not to special-case the handling of some symbols in core compiler logic...

[LPTK]

when writing new Foo(0), we are referring to the construction function, instead of the class definition

No, this isn't referring to the construction function. It should be referring to the class. Can you please try to fix it?

By the way, are you running your pass before or after resolution? The latter would make more sense.

[NeilKleistGao]

Can you please try to fix it?

The information is correct. I just need to retrieve it from the disamb field.

are you running your pass before or after resolution?

After.

---

Other problems are addressed (except for the unexpected failing in CI).

[LPTK]

No, this isn't referring to the construction function. It should be referring to the class. Can you please try to fix it?

The information is correct.

I checked, and the base reference is to the BMS of the class, not to the "construction function". The BMS represents an overloaded definition, which includes both a term (the function term) and a class. The fact that the JS backend compiles the class as a member of the function is irrelevant and has no manifestation in the IR, so I think you were just confused about the semantics of BMSs.

[LPTK]

except for the unexpected failing in CI

Yeah, working on fixing it now.

[LPTK]

Please fix the conflict.

[LPTK]

LGTM