I use the (menhir) stanza in dune to compile grammars, but I don’t know how to conveniently use the menhir --explain feature.
The naïve approach of using (flags --explain) used to work before the level of sandboxing introduced in dune.3.0 (at that time, *.conflicts files were generated in _build/$profile), but since dune 3.0, I don’t know how to keep and where to find these files: currently, I circumvent the problem by running menhir --explain manually, and remove the generated file from the source tree when conflicts are solved, but that is not very convenient!
Hi @thierry-martinez, that’s an excellent question. I am not sure either this is currently possible.
Could you please create an issue on dune’s github? This will increase the chance of solving this issue, or of adding the missing bits to the documentation.
Depending on the context, I recompiled by hand the dependencies and run menhir directly in the source tree, or I relied on dune --verbose. But in the GitHub mentioned above, Alizter suggested to use dune --sandbox none to keep the .conflicts file in _build/ and that is what I use now.
Sorry to resurrect this oldish thread, but since it does not seem that the issue was addressed in dune (my understanding of the issue is that it’s not clear that it’s dune’s role to handle this file ?), I’m wondering if people here have some workarounds that ease the pain of not having access to the .conflicts file.
To summarize:
if the parser file is monolithic (a single parser.mly) I can call menhir --explain directly on the file. It works but the drawbacks is that it leaves parser.ml and parser.mli in the current directory and you have to clean them by hand (and take care to not erase parser.mly) by mistake. Also this is not so good for incremental development of the parser where I want to fix conflicts, then debug semantic actions, then add some new rules, fix conflicts etc…
if the parser is more complex (like tokens split in another file). Then it’s not so simple. Either I will take the commands from dune --verbose and replay them by hand or just put everything back in one file and do 1.
The solution of doing --sandbox none in dune does not work (in the sense that since the .conflicts file is not a target, it is removed by dune.
Honestly I think it would be fine to always call menhir with --explain and always keep the .conflicts file in the _build/.. directory. If there are no conflicts menhir creates an empty file which is fine.
I had a go at resolving this issue, but it requires changing the menhir rules in ways I don’t quite understand so I abandoned it.
If menhir devs would like this feature to be supported by Dune then it would be good if somebody could open an issue with a proposal. The technical difficulty in the PR was about when to intercept --explain. It can appear in both the menhir stanza and the env stanza under menhir flags. The first is easy to support however the second, which is arguably more useful, is harder to pull off.
I’m happy to lend pointers to anybody wanting to attempt it themselves, but it’s not a priority for me at the moment.
and do 1.