New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assertion failed: Trying to move a local VarDef after the super constructor call of a non-native JS class #4929
Comments
I can reproduce this. Thank you for filing this issue. The issue seems to be that
(it is unwilling to move the defs across the super boundary). |
If I disable the assert that moves the VarDefs, it becomes apparent why it is needed (comment mine): js class helloworld.Defined extends helloworld.Native {
constructor def constructor(arg: any): any = {
var callbackObject: any = null;
val overload: int = {
callbackObject = arg;
0
};
super((void 0), x$1); // BAD: x$1 is not assigned here!
val x$1: any = callbackObject;
/*<skip>*/;
(void 0)
}
} |
I have a WIP fix in https://github.com/gzm0/scala-js/tree/fix-default-js-ctor-params for this. But I feel it needs to be a bit more principled. I'm not sure how much time I'll have to work on this, hence sharing my results so far. |
Other data point: whether the parent class is native or not does not matter. It can be a non-native JS class and the same issue appears. |
Previously, the logic was based on moving statements after the constructor by default, but keep selected ones before. The list of what to keep turned out to be too restrictive, and it was not clear how to expand it in a principled way. Instead, we now reverse that logic. We keep statements where they are by default, and only move `C.this.field = ident;` statements after the super constructor call. This requires only a little bit of special-casing for outer pointer null checks. Fortunately, we already some logic to identify and decompose those, which we reuse here.
Previously, the logic was based on moving statements after the constructor by default, but keep selected ones before. The list of what to keep turned out to be too restrictive, and it was not clear how to expand it in a principled way. Instead, we now reverse that logic. We keep statements where they are by default, and only move `C.this.field = ident;` statements after the super constructor call. This requires only a little bit of special-casing for outer pointer null checks. Fortunately, we already some logic to identify and decompose those, which we reuse here.
Previously, the logic was based on moving statements after the constructor by default, but keep selected ones before. The list of what to keep turned out to be too restrictive, and it was not clear how to expand it in a principled way. Instead, we now reverse that logic. We keep statements where they are by default, and only move `C.this.field = ident;` statements after the super constructor call. This requires only a little bit of special-casing for outer pointer null checks. Fortunately, we already some logic to identify and decompose those, which we reuse here.
Previously, we moved all statements in the constructors after the super constructor call. However, it turns out that there are statements that must be kept before, notably local `val`s generated for default arguments to the super constructor. We now keep statements where they are by default. We only move statements of the form `C.this.field = ident;`, which are the only ones that require access to `this`. This requires only a little bit of special-casing for outer pointer null checks. Fortunately, we already had some logic to identify and decompose those, which we reuse here.
Fix #4929: Fix logic for moving early assignements in JS ctors.
…n JS ctors. Previously, we moved all statements in the constructors after the super constructor call. However, it turns out that there are statements that must be kept before, notably local `val`s generated for default arguments to the super constructor. We now keep statements where they are by default. We only move statements of the form `C.this.field = ident;`, which are the only ones that require access to `this`. Forward port of the upstream commit scala-js/scala-js@2e4594f
…n JS ctors. Previously, we moved all statements in the constructors after the super constructor call. However, it turns out that there are statements that must be kept before, notably local `val`s generated for default arguments to the super constructor. We now keep statements where they are by default. We only move statements of the form `C.this.field = ident;`, which are the only ones that require access to `this`. Forward port of the upstream commit scala-js/scala-js@2e4594f
…n JS ctors. Previously, we moved all statements in the constructors after the super constructor call. However, it turns out that there are statements that must be kept before, notably local `val`s generated for default arguments to the super constructor. We now keep statements where they are by default. We only move statements of the form `C.this.field = ident;`, which are the only ones that require access to `this`. Forward port of the upstream commit scala-js/scala-js@2e4594f
…n JS ctors. Previously, we moved all statements in the constructors after the super constructor call. However, it turns out that there are statements that must be kept before, notably local `val`s generated for default arguments to the super constructor. We now keep statements where they are by default. We only move statements of the form `C.this.field = ident;`, which are the only ones that require access to `this`. Forward port of the upstream commit scala-js/scala-js@2e4594f
When compiling my project using my own facades for magenta.ts and tone.js, I get following Scala.js assertion:
[error] Trying to move a local VarDef after the super constructor call of a non-native JS class
The minimal repro code (using Scala 2.13.18 and Scala.js 1.15.0):
Note: I get no error when trying this with Scala 3.2.1 and Scala.js 1.15.
I guess there is probably some error in my code or in the facade, but the assertion is not very helpful.
Online repro: https://scribble.ninja/u/OndrejSpanel/crxnynclgqgzlfdcltblxjpofdqy
The text was updated successfully, but these errors were encountered: