Rakudo RT#102994: Add flag indicating HLL init status on StaticFrame

[jstuder-gh]

Add a value that indicates whether the lexical in the static frame has
been assigned a value by the HLL (flag set via extop on HLL side).

This change is being made to coincide with a Rakudo development
regarding statevar initialization.

See RT#102994

[jstuder-gh]

See rakudo/rakudo#1539

[jnthn]

This won't work; state variables exist per closure clone.

[jstuder-gh]

On the HLL side, the p6stateinit extop is using the existing p6stateinit logic and deferring to that. So
the MVM_FRAME_FLAG_STATE_INIT set on the frames determines that when assignment occurs with the HLL init flag acting as a fallback.

MVMint64 do_init = tc->cur_frame->flags & MVM_FRAME_FLAG_STATE_INIT ? 1 : 0;

...

GET_REG(tc, 0).i64 = do_init || !*is_hll_init;

It appears to work in practice, at least for the scenario presented in the Rakudo PR. Is this likely to fail given more complicated scenarios? If you think this is a wrong way to go about it, I can rework it. I
would just need you to point me in the right direction.

[jstuder-gh]

It does indeed fail to work in more complicated scenarios
Given the following:

say do for ^5 {
    sub f($x) {
        return if $x;
        state $y = 5;
        $y
    };
    f 1;
    f 0
}

This results in:

(5 (Any) (Any) (Any) (Any))

I just want to make sure that I have what you are saying correct:

In Rakudo, a block that is declared "declaration_static" has a static frame created for it. Each closure or clone creates a new frame which inherits certain data from the static frame. The issue here is that the statevars exist per clone where the static frame is shared among all instances (and thus all invocations). Is this correct?

[jstuder-gh]

The CodeRef is shared between frames invoked from the same closure but not all like the static frame, is it not? So any statevar init indicator could go there?

I suppose it should have been obvious considering that the statevar values per frame are retrieved from there, but somehow it didn't click.

[jnthn]

Yes, alongside the state values (which are in the code object) would be the place for it to go, since they share the same lifecycle.

[jstuder-gh]

Thanks for confirming. I'll have another go at it and submit a working version at a later date.