Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile-time fatal error when we write external definitions with wrong signatures #7408

Closed
vicuna opened this issue Nov 11, 2016 · 10 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link

commented Nov 11, 2016

Original bug ID: 7408
Reporter: Kakadu
Assigned to: @nojb
Status: resolved (set by @nojb on 2018-09-04T04:41:23Z)
Resolution: fixed
Severity: feature
Version: 4.03.0
Target version: 4.08.0+dev/beta1/beta2
Category: middle end (typedtree to clambda)
Tags: junior_job
Has duplicate: #7846
Related to: #6151
Monitored by: @nojb @yallop

Bug description

Both, byte- and native-code compiler. 4.03 and 4.04 are affected.

Additional information

? /tmp cat id.ml
external f: 'a -> 'b -> 'a = "%identity"

let () = print_endline @@ f "a" 1
? /tmp ocamlc id.ml

Fatal error: Bytegen.comp_primitive
Fatal error: exception Misc.Fatal_error

@vicuna

This comment has been minimized.

Copy link
Author

commented Nov 11, 2016

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.

@vicuna

This comment has been minimized.

Copy link
Author

commented Nov 12, 2016

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.

@vicuna

This comment has been minimized.

Copy link
Author

commented Dec 5, 2016

Comment author: @xavierleroy

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

@vicuna

This comment has been minimized.

Copy link
Author

commented Dec 7, 2016

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.

@vicuna

This comment has been minimized.

Copy link
Author

commented Dec 7, 2016

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.)

@vicuna

This comment has been minimized.

Copy link
Author

commented Dec 7, 2016

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.

@vicuna

This comment has been minimized.

Copy link
Author

commented Dec 8, 2016

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.

@vicuna

This comment has been minimized.

Copy link
Author

commented Dec 8, 2016

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).

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 3, 2018

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.

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 4, 2018

Comment author: @nojb

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.