Joseph Ferano
8ff8a71de8
Item 17 left this as a loose end: flan_vec_as_slice returns a slice by value and should hit the "aggregate return" refusal, bounds-condition.flan exercises it in and out of bounds and matches, and nobody traced why. It is the first of the two possibilities that report named — the refusal is narrower than it reads, and nothing is going right by accident. flan_vec_as_slice's Flan-level return type is Unit. check.ml builds it as [rt loc Types.Unit "flan_vec_as_slice"] and flan_rt.c writes the two words through a [void *out] parameter, so [is_void rty] answers first and the [is_agg rty] test below it is never reached. That is not one symbol's accident, it is the convention. Every aggregate-valued runtime result crosses through an out-pointer the checker allocates; every other [rt] builder in check.ml answers Unit, an Int, a Ptr, an Alloc or a Handle. And the other user of this path, a [declare]d C function, is covered by [crossable], which admits String and Slice only as a parameter and refuses an aggregate return outright. So there is no sret convention to build for Rt, and building one would be worse than the refusal: the C boundary wants SysV classification — a 16-byte slice comes back in rax:rdx — and not the hidden-pointer convention this backend uses internally. There is no classifier in the file and nothing to test one against. The line stays as a guard against those two rules changing, and now says which rules and what the work would actually be. With it goes the rest of item 16's claim that the container runtime is unexercised. It is: Vec and Map through vec.flan, vec-of-vec.flan, maps.flan and map-iter.flan, and Pool through registry.flan, handles.flan, generics.flan and pool-stale-region.flan. All match.
