Communicate frontend layouts to lambda

[ccasin]

This PR hooks up the frontend's inferred layouts to the calculation of Lambda.layouts, a necessary step for unboxed floats.

The Typeopt module, used by the translation to lambda, has a function called layout that computes the Lambda.layout of a type. This information is used by various middle-end optimizations. Previously, this function simply assumed the type it was passed had sort value. Now it gets that information from the front-end, at least in the places we'll need non-values for unboxed floats.

The first commit changes Lambda.layout to take the extra sort argument, but doesn't yet compute correct sorts. Instead, we always pass it value. Rather than just writing "Sort.value" explicitly everywhere, I added a bunch of named sorts to layouts.ml (e.g., sort_function_arg and sort_tuple_element) and pass those. These named sorts are separated into three categories:

• Places where we need to allow other sorts for layouts v2.
• Places we'll eventually want to allow other sorts, but don't need to for v2.
• Places that will always be values.

The subsequent commits delete the named sorts in the first category, getting the sort information from the type system instead. Sorts were added in a few places in the typed tree to support this.

(Aside: It would be nice to used named layouts and sorts like this everywhere in the compiler. But this is already a reasonably sized PR that needs to be reviewed carefully, so I've left that for another day.)

Testing: There aren't many new tests, because most of this is already covered by the layouts tests. You will see that the relevant sanity check errors have changed to mention Typeopt.layout instead of value_kind. If this PR is correct, every layouts test that currently uses void or any to exercise a feature that we'll need to work for float# should now hit the sanity check in Typeopt.layout instead of the one in value_kind (because we're passing the accurate sort information from the type system).

Reviewing: This needs both type system and middle-end review, and there are a couple small bits in the backend. @goldfirere to review or delegate for the type system. @mshinwell can you nominate someone for the middle-end bits (and the backend bits if needed)? It's probably easiest to review commit by commit, for the main reviewers.

This should be reviewed carefully. It would be hard for this PR to introduce miscompilations because we still have the sanity checks for void. But, when we add unboxed float, we'll be relying on this code to be correct and won't re-review it then.

Notes for reviewers about some of the individual commits:

• sort_function_arg

  This required adding sorts to Texp_function in Typedtree, and computing those sorts in various places. An alternative would be to add sorts to Tarrow in Types. This would probably save some work, but isn't compatible with our plan to allow any in arrows, and feels inelegant because the sort information would be duplicated in the Tarrow and its components.

• sort_function_return, sort_let_bound, and sort_pattern_var

  These commits and the one after them change the interfaces in lambda/matching.ml and lambda/translcore.ml a bit gratuitously. A thing that has been creeping up on us for a while now is that many functions in these files need to take multiple layouts or sorts as arguments, and lots of those arguments had names like value_kind which is both no longer accurate and totally unclear (the value_kind of which thing?!).

  The functions touched in these commits now uniformly take named arguments for layouts and sorts, and the names are all ~arg_layout, ~arg_sort, ~return_layout, or ~return_sort. I think it's a lot clearer. Functions never take the layout and the sort for the same thing - if we need the sort again after we've already calculated the Lambda.layout, we can easily and cheaply translate it back (sort_of_layout has been added for this purpose). I tried a few iterations where we passed both sorts and layouts down through the translation and into matching, but it was really verbose and it was often unclear which to use.

• sort_prim_arg and sort_prim_value

  Something slightly scary which pre-dates this PR is that there isn't much type checking for primitives. So, for example, this type checks and segfaults

  external eq : 'a -> 'b -> string = "%equal"
  
  let _ = Printf.printf "string? %s" (eq 42 true)

  Now you could also get the layouts wrong! I think we're not really making this problem much worse from a front-end perspective, but it would be nice to do something about in the future.

  On the other hand, primitives now carry sort information with them, and that sort information will need to be used by the middle-end and backend. I haven't done that yet, because it seems hard to test without another sort, but someone knowlegeable should tell me whether this approach is reasonable and whether the comments I've left saying "this bit needs to change" are correct. I'm sure I haven't identified all such places.

• sort_statement

  We used to allow any layout and now require a sort for the type of statements (things like e1 in e1; e2). This isn't much of a restriction, though. You can still write assert false; e2, because we can give assert false the type 'a : 'sort_var.

[goldfirere]

I did not review the following directories:

• backend
• middle_end
• ocaml/lambda
• ocaml/middle_end

I did review the following:

• ocaml/asmcomp
• ocaml/bytecomp
• ocaml/ocamldoc
• ocaml/testsuite
• ocaml/typing, alphabetically through layouts.mli (when I timed out)

I will review the rest of typing, along with lambda/matching.ml. I would appreciate review of the parts I know less about; @mshinwell suggested @Ekdohibs might do this.

[goldfirere]

I have now finished reviewing ocaml/typing. I will attempt matching.ml, but not today.

[goldfirere]

I have now finished reviewing ocaml/typing. I will attempt matching.ml, but not today.

[goldfirere]

Reviewed files with "matching" or "comprehension" in their filename.

[goldfirere]

A bit more, after looking at recent commits

[goldfirere]

OK. I have finished my initial review here.

Review not done:

• backend
• middle_end
• ocaml/lambda (except that I did do review for matching.ml, matching.mli, and anything with "comprehension" in the title)
• ocaml/middle_end

@mshinwell and @Ekdohibs are good reviewers for those pieces

[Ekdohibs]

I have reviewed the files that @goldfirere did not, see comments.

[gretay-js]

Only for files in backend and asmcomp owned by me.
It looks like I am also owner of testsuite/tests/typing-layouts files, which is obviously wrong.

[mshinwell]

This is ok given the reviews of @goldfirere , @Ekdohibs and @gretay-js