Support stack_ for primitives that allocate

[riaqn]

This PR allows writing stack_ (ref "hello").

See my comments below for details.

[goldfirere]

I see why we might want this, but was this change motivated by a concrete use? In addition, a return mode of poly isn’t always right — for example, %identity has that property, I believe, but isn’t an allocation. If we wanted to do this, I think it would be better just to list out the primitives that optionally stack-allocate. But I probably favor not doing this at all, but instead to make the stack-allocation apparent in the named external, like ref_stack. If someone wants to ensure a stack allocation, they just use ref_stack.

[goldfirere]

OK — I found the Slack thread that provides more context (and that already suggests not to use the “poly” criterion). But I still think that we should just have a stack_ref instead of allowing this. Let’s continue the design debate on Slack.

[riaqn]

As discussed offline, we now introduce a new attribute [@alloc_poly] on external:

external[@alloc_poly] ref : 'a -> ('a ref[@local_opt]) = "%makemutable"

which indicates that the [@local_opt] is in fact an allocation. Both the behavior of stack_, and the register_allocation in type_ident are improved based on this.

This change needs to be noted upon release: users might need to update their external to use this attribute, to ensure the existing register_allocation optimization continues to happen.

Updated stdlib to use this, so that the tests pass. I might have missed some (and will be fixed in future PRs).

[riaqn]

This is currently blocked by some miscompilation issue on arm64 and GI regalloc (shown in CI). AFAIK @xclerc is looking.

[riaqn]

Per offline discussion with @goldfirere , this is now implemented differently and no longer requires additional user annotations.

When user writes stack_ (%foo bar) where foo is a primitive, the typing makes the whole expression local and triggers mode error if the expected mode is more strict than that. If typing goes through, it gets picked up again by lambda and:

• check that foo is indeed a lambda primitive that allocates. External C functions will be rejected. Nonallocating primitives such as %identity will be rejected.
• if so, check that foo, given how its declared (by local_opt or local_), will allocate on stack.

[goldfirere]

Looks great. Thanks