I'm worried that the free_names_of_body name would mislead us into thinking that all the free names have been computed, while only the free continuations are included. It turns out that Let_cont.create_non_recursive only reads the continuation part and discards the rest, so this ends up fine, but I think for a bit more clarity I'd change the label of Let_cont.create_non_recursive to free_conts_of_body (or free_continuations_of_body if it's not too verbose).

Apart from that I haven't seen anything in the diff that looks suspicious. I'll look a bit more to see if I can find code not in the diff that should have been updated.

I'm worried that the free_names_of_body name would mislead us into thinking that all the free names have been computed, while only the free continuations are included. It turns out that Let_cont.create_non_recursive only reads the continuation part and discards the rest, so this ends up fine, but I think for a bit more clarity I'd change the label of Let_cont.create_non_recursive to free_conts_of_body (or free_continuations_of_body if it's not too verbose).

Wouldn't it be misleading either way ? In a lot of cases this label seems to be given more thorough Name_occurrences, the same as for other constructs with this label in fact.
In the case of this particular usage, the Acc field makes clear the distinction between what the label expects (whether it discards most of it or not) and what is given.

In the case of this particular usage, the Acc field makes clear the distinction between what the label expects (whether it discards most of it or not) and what is given.

What was not obvious to me, when reading your PR, was that Let_cont.create_non_recursive would actually work if you pass it a Name_occurrences.t that only contains continuations. Maybe using Let_cont.create_non_recursive' would have been more explicit ? Alternatively, maybe add a comment noting that only the continuation part of the Name_occurrences.t structure is read, so it's fine to pass it a structure that does not accurately track the other free names.

Please also add a comment to those creation functions themselves that some callers are relying on this behaviour.

There's a conflict with #500 that was merged recently. Since #501 is going to introduce another conflict and is probably going to be merged soon, you may want to wait until that is done to rebase and fix the conflicts.

Just merged #501 so if you rebase now everything should be fine, apologies for the disruption.