Don't generate fields for BoxedUnit val and var

[nicolasstucki]

This is intended as a way to not generate fields
for phantom fields, which by this time are erased
to BoxedUnit fields.

[DarkDimius]

Nice idea :-)
Shouldn't we also do it for our bottom types: Null & Nothing?

[smarter]

What happens if you extend a class where val foo: Any is abstract with val foo: Unit = ... ?

[DarkDimius]

@smarter, superclass will have abstract getter and no actual field, so it should work fine.

[sjrd]

If that happens before the backend, it will be virtually impossible for the Scala.js to correctly implement its interop with JS. In a Scala.js-defined JS class, such a field must exist and be visible from JavaScript with the value undefined. Same thing with Null.

[adriaanm]

You should also exclude @volatile fields. (This trick is used in ParIterableLike.scala: @volatile var result: Unit = ())

[nicolasstucki]

@adriaanm I would assume that it is only necessary for @volitile Unit fields.Null fields will always return null and Nothing field will throw before the object is completely instantiated. Is there some weird usage of the latter that I might be missing?

[nicolasstucki]

@sjrd I will try to put it in it's own miniphase just before backend.

[smarter]

@nicolassstucki Don't we want phantom fields to also be optimized out in other backends?

[nicolasstucki]

@smarter good point. @sjrd what king of interop with JS do you expect to have on Unit fields?

[sjrd]

If you have the following Scala.js class:

@ScalaJSDefined
class Foo extends js.Object {
  val x: Unit = ()
}

Then the following must be true to respect the Scala.js interop spec:

val foo: Foo = new Foo
foo.hasOwnProperty("x")

And also from JS, if you have a foo:

foo.hasOwnProperty("x")

[DarkDimius]

@nicolasstucki,

Null fields will always return null and Nothing field will throw before the object is completely instantiated. Is there some weird usage of the latter that I might be missing?

It's not about the value they return, it's about memory model and reordering of operations in JVM.
Reading and writing Null field does introduce read\write barriers. Same with Nothing, you can actually write null into it(and read it!) introducing a memory barrier.

I'd propose to include a check that the field is indeed not a @volatile field for all types, including Unit.

[smarter]

typo: volitile -> volatile

[smarter]

I don't think it makes sense to allow phantom var. var implies runtime semantics that just make no sense for phantoms.