Incorrect module name is passed to Persistent_env.acknowledge_pers_struct with -annot on OCaml 4.10

[kit-ty-kate]

links.0.9 does not compile with OCaml 4.10, after a bit of clean up, the following error message appears when compiling several modules, e.g.:

File "core/irTransform.ml", line 1:
Error: Wrong file naming: /home/kit_ty_kate/.opam/4.10/lib/result/result.cmi
       contains the compiled interface for  Result when result was expected

I tried to reproduce it with a smaller test case but I wasn't able to get one, so here is as far as I went in my debugging session:

• Persistent_env.acknowledge_pers_struct gets called with modname = "result" and ps.ps_name = "Result", I'm guessing modname should be a capitalized and something went wrong along the way.
• The same modules that fail to compile do not if -annot is removed from the arguments.
• Here is the command used and the call stack right before ocamlc fails:

$ gdb --args /home/kit_ty_kate/.opam/4.10/bin/ocamlc -annot -I core/.links_core.objs/byte -I /home/kit_ty_kate/.opam/4.10/lib/result -I lens/.links_lens.objs/byte -open Links_core -c core/irTransform.pp.ml
[...]
#0  camlPersistent_env__acknowledge_pers_struct_1703 () at typing/persistent_env.ml:168
#1  0x00005555559145d9 in camlPersistent_env__find_pers_struct_1734 () at typing/persistent_env.ml:225
#2  0x00005555559213a9 in camlEnv__lookup_ident_module_3330 () at typing/persistent_env.ml:264
#3  0x000055555592255f in camlEnv__lookup_module_3434 () at typing/env.ml:2444
#4  0x00005555559535a6 in camlPrinttyp__to_lookup_457 () at typing/printtyp.ml:84
#5  0x00005555559549b4 in camlPrinttyp__env_ident_1642 () at typing/printtyp.ml:271
#6  0x0000555555955065 in camlPrinttyp__ident_name_1670 () at typing/printtyp.ml:310
#7  0x00005555559556ac in camlPrinttyp__tree_of_path_1720 () at typing/printtyp.ml:394
#8  0x0000555555955736 in camlPrinttyp__tree_of_path_1720 () at typing/printtyp.ml:398
#9  0x0000555555959b2c in camlPrinttyp__pr_typ_2291 () at typing/printtyp.ml:961
#10 0x000055555595aab1 in camlPrinttyp__typexp_2400 () at typing/printtyp.ml:1098
#11 0x000055555586629c in camlMisc__try_finally_inner_3884 () at utils/misc.ml:31
#12 0x0000555555993732 in camlStypes__print_info_467 () at typing/stypes.ml:162
#13 0x0000555555a624f8 in camlStdlib__list__fold_left_272 () at list.ml:121
#14 0x0000555555993932 in camlStypes__do_dump_669 () at typing/stypes.ml:200
#15 0x0000555555867cee in camlMisc__output_to_file_via_temporary_inner_4008 () at utils/misc.ml:355
#16 0x0000555555993850 in camlStypes__dump_666 () at typing/stypes.ml:204
#17 0x00005555558662ed in camlMisc__try_finally_inner_3884 () at utils/misc.ml:42
#18 0x0000555555a5dbb8 in camlCompile_common__fun_1256 () at driver/compile_common.ml:123
#19 0x000055555586629c in camlMisc__try_finally_inner_3884 () at utils/misc.ml:31
#20 0x000055555586629c in camlMisc__try_finally_inner_3884 () at utils/misc.ml:31
#21 0x000055555586629c in camlMisc__try_finally_inner_3884 () at utils/misc.ml:31
#22 0x0000555555a41d3f in camlCompenv__process_action_896 () at driver/compenv.ml:597
#23 0x0000555555a62441 in camlStdlib__list__iter_258 () at list.ml:110
#24 0x0000555555a42673 in camlCompenv__process_deferred_actions_958 () at driver/compenv.ml:673
#25 0x0000555555852663 in camlMain__main_1608 () at driver/main.ml:38
#26 0x0000555555852b8b in camlMain__entry () at driver/main.ml:111
#27 0x000055555584f059 in caml_program ()
#28 0x0000555555ac7304 in caml_start_program ()
#29 0x0000555555ac7afc in caml_startup_common (argv=0x7fffffffe5b8, pooling=<optimized out>, pooling@entry=0) at startup_nat.c:162
#30 0x0000555555ac7b4b in caml_startup_exn (argv=<optimized out>) at startup_nat.c:172
#31 caml_startup (argv=<optimized out>) at startup_nat.c:172
#32 0x000055555584e64c in main (argc=<optimized out>, argv=<optimized out>) at main.c:44
(gdb) c
Continuing.
Result <> result
File "core/irTransform.ml", line 1:
Error: Wrong file naming: /home/kit_ty_kate/.opam/4.10/lib/result/result.cmi
       contains the compiled interface for  Result when result was expected

And I'm afraid that's all I have for now, I don't know enough about the internals of the compiler to guess where to poke further in a clever way. I might add more debug message to the functions shown above in the backtrace later but it might take some time so if someone here has a good enough guess that might speed up the debugging process.

To test it locally here are the necessary steps:

$ opam remote add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git
$ opam install --deps-only links.0.9
$ git clone git://github.com/links-lang/links.git
$ cd links
$ dune build -p links --profile=dev

Happy new year!

[gasche]

Note: on my machine (opam 2.0.4), opam install --deps-only links.0.9 fails because links is not installable on 4.10 (it has < "4.10" for its OCaml dependency), although --deps-only should not require the package to be installable. Odd.

[kit-ty-kate]

oh I forgot to add the --ignore-constraints-on ocaml arguments

[gasche]

I don't know what the issue is, but I will try to reproduce locally. I think the easiest way to locate a compatibility issue is to bisect (one could start by checking #2228, which included a fair amount of code churn in this part of the compiler, as a potential culprit), and then work from the patch that provoked the failure.

Note that -annot is considered essentially-deprecated nowadays (it creates the .annot files that are used by Emacs show-type command that is now superseded by Merlin, which does this better and much more), and it is surprising that a release build of some user-facing software would use it. If the links build could be fixed by getting rid of -annot, that would be an easy workaround to make. But even if the symptom depends on -annot for links, it looks like a more fundamental issue that could potentially be reached by other non-annot-using code, so it is worth investigating.

[gasche]

$ dune build -p links --profile=dev
dune: Cannot use --profile and -p simultaneously

Edit: Nevermind, resetting opam env fixed this error.

[gasche]

Unfortunately I have no progress to report here; reproducing the build with earlier versions of the 4.10 development branch is difficult, and I couldn't do any actual bisecting. (One option I would consider is to not rebuild the opam switch each time, but simply rebuild the compiler and change-in-place the compiler installation. Hopefully the regression is within a range of commits where this approach is possible -- the object file formats are stable enough.)