dune
dune copied to clipboard
-opaque option breaks equivalence between release and dev compilation in presence of [@inline always]
Expected Behavior
dune build and dune build --release should both work or both fail
Actual Behavior
If the code contains [@inline always], dune build may fail with error File "test.ml", line 12, characters 18-52: 12 | module FloatMat = Mat.Make [@inlined always] (Float) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error (warning 55): Cannot inline: Unknown function
because of the -opaque option, while dune build --release succeed.
Reproduction
Easy!
- Proposed solution remove warn_error for warning 55 and maybe others when compiling in dev mode.
- Other possible solution: do not use -opaque is [@inline always] and similar appears in the code (if the user thinks inlining is really important, one should not use -opaque.
- PR with a reproducing test:
- Create a first file with a functor or funciton
- Ask to inline this in another file with [@inline always]
Specifications
- Version of
dune(output ofdune --version): 2.7.1 - Version of
ocaml(output ofocamlc --version): 3.11.1 and 3.11.1+flambda - Operating system (distribution and version): debian testing
Additional information
- Link to gist with verbose output (run
dunewith the--verboseflag):
Thank you for the report. Now that you points to it, it is strange that it doesn't appeared sooner. The fixes are indeed easy, but I don't know which one I prefer yet.
We should just completely ignore warning 55 in dev mode. This warning cannot be checked for functions that comes from dependencies since the compiler has no access to the cmx files of dependencies in development mode.
dune build and dune build --release should both work or both fail
This expectation is too high. The development mode is supposed to be stricter, so a reasonable expectation is that if the dev build succeed then the release build will succeed as well. I say "supposed to" because as shown in this ticket, this is not always the case.
We could also allow the user to selectively disable -opaque. If they prefer @inline checking in development
That would work as well. Though I can of think we should keep it simple.
We discussed it in the dev meeting and decided to disable warning 55 in dev mode starting with lang dune >= 2.9.
Actually strike that. From further discussion, disabling this warning entirely is not great either. It doesn't give the user the opportunity to see that their attribute are not honoured. We also discussed not changing the status of this warning and just let it be a warning that is not treated as error, but that is not great either for the usual reasons.
For now we are keeping the status quo, but here are a few things you can do:
- unconditionally disable warninng 55
- disable warning 55 in dev mode only, by writing the following in your
dunefile:
You can put this in a(env (dev (flags :standard -w -55)))dunefile at the root of your project and it will apply to the whole project. - when appropriate, rather than using
[@inlined ...]at the call site, use[@inline ...]at the definition site
Just clarifying the downside of disabling this warning in dev: the downside is that the build may succeed in dev and then fail in release mode, which is bad for certain workflows, e.g. if your CI runs in dev mode only.
Le 21-01-27 09:21:08, Arseniy Alekseyev a écrit :
Just clarifying the downside of disabling this warning in dev: the downside is that the build may succeed in dev and then fail in release mode, which is bad for certain workflows, e.g. if your CI runs in dev mode only.
By the way: what are the differences between dev and release mode (other that -opaque) and is it possible to remove -opaque from dev mode ?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.*
There are more warnings enabled as error in dev mode than in release mode. If you use js_of_ocaml, you get separate compilation in dev mode, which leads to faster incremental builds but bigger generated .js files.
It is not possible to remove -opaque in dev mode.
Hi there! Was there any progress on this issue? For the record, this issue was mentioned on the OCaml Discuss.