[lworld] VerifyError: Bad type on operand stack, limitation in javac for value type constructors

[John Rose]

On Jul 16, 2018, at 9:53 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
> 
> There was both a lowering problem and a code generation problem.
> Given:
> 
>     x = y = 1234;
> 
> Earlier it was being lowered to:
> 
> $value = __WithField($value.x, $value = __WithField($value.y, 1234));
> 
> which is bogus.
> 
> Now we lower the above chained assignment to:
> 
> $value = __WithField($value.x, ($value = __WithField($value.y, 1234)).y);
> 
> Now the lowering is good, but it complicates code generation due to side effects peculiar to values:
> 
> For the outer withfield if we *first* load the value type instance onto the operand stack and *then*
> compute and load the expression ($value = __WithField($value.y, 1234)).y, we have trouble: Since the value type instance already loaded onto the operand stack is the one being modified by the subexpression
> ($value = __WithField($value.y, 1234)).y.
> 
> So the right code generation is to first compute ($value = __WithField($value.y, 1234)).y with the
> attendant updates to $value (the factory's return value) and *then* load the *modified* value.
> 
> Only complication is this leaves the withfield instructions operands in the reverse order.

This lowered expression would do the job in the right order, correct?

$value = __WithField(($value = __WithField($value.y, 1234)).x, $value.y);