13034 error messages: mismatched labels

[Octachron]

This PR adds a specialized explanation for mismatched function labels in type error messages.
For instance, in

module Label1 : sig
  val f: int -> unit
end = struct
  let f ~x = ()
end

the existing error message

      Modules do not match:
        sig val f : x:'a -> unit end
      is not included in
        sig val f : int -> unit end
      Values do not match:
        val f : x:'a -> unit
      is not included in
        val f : int -> unit
      The type "x:'a -> unit" is not compatible with the type "int -> unit"

is extended with

      The argument "x" is labeled, but an unlabeled argument was expected

This complements the existing specialized error message for syntactic argument with a label incompatible with the expected type.

close #13034

[gasche]

Nitpick: wouldn't this be easier on the eye with the error case first?

if not (compatible_labels ...) then
  raise_for ...;
unify uenv t1 t2; unify uenv u1 u2;
begin match ... with
  ...
end

(Same question in the other, simpler cases.)

[Octachron]

Why not?

[samsa1]

Woudn't it be even simpler if we moved the raise inside the compatible_labels function ?
This would reduce code duplication (and even more if more label comparison are added).

[Octachron]

There are calls to compatible_labels in mcomp and the subtyping mode that doesn't raise the exception, either because we are only checking compatibility or because we are storing an error trace for later use.

However, we could have a raise_on_incompatible_labels function which has the advantage of keeping the control flow obvious.

[gasche]

I am uneasy with the wording The optional argument "?x", because ?x is a label and not an argument`. I proposed some reformulations that avoid this issue. Also in the case of a mismatch between an optional and a non-optional label, I propose to simplify with a more approximative but shorter error message. Feel free to adapt the suggestions or discard them outright.

[gasche]

Proposal: The argument has label "x", but ....

[Octachron]

Counterproposal: The first argument is labeled "x"

[gasche]

Fine with me.

[gasche]

The argument has label "x", ...`

[gasche]

The argument has label ?x, ....

[gasche]

Labels "?x" and "x" do not match.

[Octachron]

I disagree with repeating twice the same name with one minute change.
I propose: Label "?x" was expected to not be optional.

[gasche]

Wait, what would the error be on a mismatch between ?x:int -> unit and y:int -> unit? I assumed that the use of x on both sides was irrelevant to the current situation and wording.

[Octachron]

In this case, Labels "?x" and "y" do not match seems a good simplification to me (the previous error message was The optional argument "?x" was expected to be a labeled argument named "y")

[gasche]

A label "?x" was expected.

[gasche]

Side remark: the absence of a final . at the end of these captialized sentences is odd, but this is orthogonal to the current change.

[Octachron]

I agree and generally struggle to remember to not add period in those explanations.