work around scala bug 4762

[bbrehm]

cf scala/bug#4762 and the benchmarks in joernio/flatgraph#11

Generally, I think we need a custom linter rule that forbids this kind of shadowing of superclass fields.

Indeed, my preferred solution to 4762 would be to forbid the compiler from ever silently generating fields from class parameters in non-anonymous classes (i.e. outside of closures).

In other words, class foo(x:Int){def getX:Int = x} would become a warning and would demand a rewrite to class foo(private val x:Int) {def getX:Int = x}.

The general idea of "muh muh the compiler will figure out what fields you need" is imo a braindead stupid decision by the scala language. The single most important fact of a data type, i.e. non-singleton class, is its memory layout, and making it non-trivial to predict the set of fields from a class definition is just painful. Non-triviality is evidenced by the fact that we have wasted 8 bytes per node for god knows how long.

In this specific case, I think the issue is that the read of id in def product refers to the scala class parameter, while all other ones refer to the base class id field. Hence, the derived (duplicate) id field needs to be kept around for def product. Now both are final; so I can't tell whether the scala compiler is too stupid/buggy to figure out that only one is needed, or whether it is defensive enough to accommodate cases where people use reflection to modify a final field, or whether it needs to be that defensive to accommodate binary compat (i.e. runtime version of baseclass NodeRef differs from compile time version).

[ml86]

Please remove the "wtflol" and add 1-2 sentence as explanation why we need different identifiers and than reference the bug issue. This makes it easier to understand.

[mpollmeier]

wowsies

[mpollmeier]

[mpollmeier]

sorry for the approval/disapproval cycle, i was testing some local changes and must have been confused

[mpollmeier]

fwiw this bug was "ported" to scala3