In #2180 there were really two fixes:

• changes to Call_kind in Flambda 2 to deal with the accidental omission of the region variable for C calls during a recent improvement/refactoring PR (Better region handling for functions #1871).
• a change in Lambda.primitive_may_allocate to correctly handle the case when prim_alloc is false but in fact the external function locally allocates. This appears to have been a pre-existing bug. (It is permitted to write such code iff you are certain the compiler used will always be configured with stack allocation.)

Unfortunately the second change has revealed another problem. Some primitives, for example one declared like this:

external float_of_bits : (int64[@local_opt]) -> (float[@local_opt])
  = "caml_int64_float_of_bits" "caml_int64_float_of_bits_unboxed"
  [@@unboxed] [@@noalloc]

end up appearing in Lambda as Prim_poly (the comment in primitive.mli is kind of misleading here). However this isn't ok from the point of view of Lambda.primitive_may_allocate and in particular its new helper function Lambda.alloc_mode_of_primitive_description (which is also used by Flambda 2). For example, the above primitive might get eta-expanded by the code in Translprim, in conjunction with a judgement that effectively turns Prim_poly (plus some extra information, the poly_mode) into Alloc_heap. This is then used to avoid inserting a region, correctly, but is not propagated further (there is nowhere to put it on the Lambda terms). We thereby end up in a situation where the Lambda code says Prim_poly, so alloc_mode_of_primitive_description says "might allocate locally" -- but the Translprim code had not inserted a region. This then causes a fatal error in Flambda 2, because if a external call might allocate locally, its applications will contain region variables. These will be unbound if the frontend failed to insert the appropriate regions (or marked the enclosing function as allowing local allocations to escape, in which case the implicit my_region function parameter would be used).

The idea of this PR is to ban Prim_poly from appearing in Lambda terms at all. It does this by making the argument of the Pccall constructor private, which necessitates only minor changes, and insisting that all constructions of it are done by supplying the return mode. This then rewrites Prim_poly into either Prim_global or Prim_local as appropriate, avoiding the above problem. It seems better than an alternative solution I considered, namely causing regions to be inserted for all Prim_poly primitive calls.