Mill module / target overriding vs Java binary compatibility

[lefou]

When overriding a target, it's possible to re-use the overridden target result. Unfortunately, referencing the super.foo() from a public def foo it is in most cases a binary incompatible change, when it wasn't referenced before. This is due to the fact how traits are encoded in the JVM, I think. This has the downside that we aren't as free as we want when it comes to target implementations. At least not, if we want to stay binary compatible, which is IMHO crucial for Mill itself and some of it's more widely used plugins.

I wonder it there is a way to prevent this by design?

Technically, it should be possible to always reference the super target without using it as a target. This should not have an impact on the target evaluation, as these targets are never executed as dependencies. So, whenever we override a target but do not plan to use the super value, we could still add a reference to the super target, but without using it's apply method. super.foo instead of super.foo(). And since this is unused boilerplate code which doesn't make sense in a code review, we could automatically do this in the T-macros. The question is, can detect whether it's needed at all, from inside the macro?

@lihaoyi WDYT?

[lihaoyi]

I think it sounds reasonable. It should be easy to add an if (false) { super.foo() } inside every def foo if such a super call exists. The macro has access to the types and inheritance hierarchy AFAIK, which should contain this information

[lefou]

Isn't if (false) { super.foo() } already triggering it's evaluation? I think it would be enough to have a if (hasASuperFoo) { super.foo }, so that the bytecode references the target, but we don't access it's value and don't trigger it's evaluation.

[lihaoyi]

Oh yes, you don't want to call it () to add an unnecessary dependency

It'll just have to be if (false) {super.foo} in the case where the super exists, and nothing otherwise.