Comment author: @xavierleroy

At least you get a compile-time error -- even if it is not pretty. I mean, it would be much worse to silently generate wrong code.

My first reaction to this PR is "just don't do that". External declarations with "%" primitives are not documented and are normally used only in the standard library.

I move to "close/no change required" this PR.

Comment author: @gasche

Xavier, I agree that it's fine to have a compiler error on this case, but I also think that an uncaught exception is not a very nice way to stop the compilation. I quickly looked at the backtrace and it is not at all obvious, to me, why it is failing at this point of the compilation (it is failing during code generation, not before, in a different path in ocamlc and ocamlopt).

I don't think that anyone should prioritize spending time on this, but (1) having a nicer error message could be nice and (2) the uncaught exception may be the symptom of something fragile in the compiler that could manifest itself in worse ways in other occasions.

I would thus be tempted to keep the PR open with a "junior job" tag: I think that understanding what is happening by investigating the trace, and reporting on whether there is a satisfying change that would improve the behavior, could be a nice onboarding task for someone interested in learning more about the compiler.

Comment author: @xavierleroy

We need to grow a sense of priority. Reclassifying as "feature wish".

Comment author: @mshinwell

I've closed I think two other PRs today that were related to the calling of % primitives, saying basically what Xavier first wrote above. I don't think these failures are a sign of something more deeply wrong; it's just that the arguments aren't checked until fairly late in the compilation pipeline.

I move that we close this PR as well, together if needs be adding a new PR for adding to the stdlib bindings for any %-primitives that are particularly heavily used.

Comment author: @mshinwell

(As for getting newcomers up to speed and priorities: I can't help but think there are straightforward issues to be fixed that will provide more value for everyone than things like this.)

Comment author: @gasche

Well if three separate people were surprised enough by the behavior to create a PR, I think it is safe to assume that many people encounter these issues through their normal development workflow and are surprised by what is happening. I would say it confirms that this is a non-null usability issue.

Comment author: @lpw25

I think I agree with Gabriel that we should check the arity of primitives explicitly in translcore. It leaves me a little uneasy that the middle-ends can have primitives with the wrong number of arguments going through them (since it is not checked until cmmgen). I'm not entirely convinced that you can't get broken behaviour rather than a compile-time error.

As a side-note, does anyone know why the "%loc_*" primitives are supported at both 0 and 1 arity in transl_primitive? The 1 arity behaviour seems very odd and I have no idea why it is there.

Comment author: @gasche

The same primitive name is used for LOC, which returns its own location, and (LOC_OF foo) which returns the location of (foo). I think this is very ugly, but I was the only one voicing that opinion when the feature was discussed (caml-devel, "add a new primitive to return location at call position", march-april-may 2014).

Comment author: smuenzel-js

I agree that not enforcing the arity throughout all the phases may end up making it easier to introduce other, related bugs in the future.

What about encoding this in the type

type 'a prim =
| Prim1 of { primitive : prim1; arg : 'a }
| Prim2 of { primitive : prim2; arg0 : 'a; arg1 : 'a }
....
or something similar.

Comment author: @nojb

Arities of %-primitives are now checked following the merge of #2015.