Sébastien Doeraene

Results 641 comments of Sébastien Doeraene

> My gut feeling is that restricting the operands lexically goes a bit far, especially if we cannot maintain the property post optimizer. This will force us to either: >...

Rebased, including adding changes in the Wasm backend (the rest is unchanged).

Ah, that is an interesting take. The typed closures PR shows that it is indeed possible to have IR types that don't have any interop semantics, by not being subtypes...

Meh, that's not so great. In addition to introducing more difficulties to handle `null`s, it reintroduces the problem that the linker must know about the `data` field of `jl.Class`. For...

FYI, I'm getting somewhere with non-nullable types in the IR, but I'm not done yet (the optimizer is not type-preserving yet, so Wasm+optimizer generates invalid Wasm code): https://github.com/sjrd/scala-js/compare/optimizer-with-webassembly...sjrd:scala-js:nullable-types-in-ir

True non-nullable types in the IR available at #5018.

I don't think that would work. Hijacked classes need a corresponding primitive type. Otherwise there's no way to implement their methods. For example, most methods of `jl.Integer` work on `this.asInstanceOf[Int]`....

Rebased to leverage the non-nullable reference types. Now the (first) argument of `Class_x` operations must be a `ClassType(jl.Class, nullable = false)`.