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

Combination of -short-paths and -no-alias-deps can create inconsistent assumptions #6812

Closed
vicuna opened this Issue Mar 12, 2015 · 2 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link
Collaborator

commented Mar 12, 2015

Original bug ID: 6812
Reporter: @sliquister
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2017-09-24T15:33:25Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.02.1
Fixed in version: 4.02.2+dev / +rc1
Category: typing
Related to: #7134

Bug description

When using -no-alias-deps in combination with a build setup where we have one module in a library that both aliases all the other modules and is used by all modules (see attached script), on type errors and with -short-paths, the compiler may start forcing the environment and load cmis for modules that aren't compiled yet (which is just a warning) or are compiled by not up to date (because they depend on the module being currently compiled for instance) which causes inconsistent assumptions.

I am not sure what the compiler should do. Obviously, not forcing aliases would the problem, but I don't know what the impact is on short-paths.

Also, in case we can kill two birds with one stone, I'll mention that the compiler prefers Lib__A.t in type errors over Lib.A.t which I suppose is expected but still a bit sad.

Steps to reproduce

I attached the script inconsistent_assumptions:

$ /tmp/inconsistent_assumptions
File "b.ml", line 1, characters 14-15:
Error: This expression has type int but an expression was expected of type
Lib.A.t = float
$ /tmp/inconsistent_assumptions -short-paths
File "b.ml", line 1:
Error: The files lib__A.cmi and lib__B.cmi make inconsistent assumptions
over interface Lib__A

Additional information

Stack trace of the compiler if it helps (that's the trace for my initial problem, not the small reproduction in the script but it should be the same):

Breakpoint 1, 0x00000000005028d0 in camlEnv__check_consistency_1494 ()
(gdb) bt
#0 0x00000000005028d0 in camlEnv__check_consistency_1494 ()
#1 0x0000000000502d63 in camlEnv__find_pers_struct_inner_3114 ()
#2 0x000000000050335b in camlEnv__find_module_1584 ()
#3 0x0000000000506260 in camlEnv__scrape_alias_2047 ()
#4 0x0000000000507c67 in camlEnv__components_of_module_maker_2158 ()
#5 0x000000000050205c in camlEnv__force_1252 ()
#6 0x00000000005000bb in camlEnv__iter_components_1902 ()
#7 0x00000000004a56a1 in camlTbl__iter_1096 ()
#8 0x00000000004a568b in camlTbl__iter_1096 ()
#9 0x0000000000617d23 in camlHashtbl__do_bucket_1138 () at hashtbl.ml:188
#10 0x00000000006190d0 in camlHashtbl__iter_1135 () at hashtbl.ml:191
#11 0x0000000000505b01 in camlEnv__iter_env_1895 ()
#12 0x0000000000531e3a in camlPrinttyp__fun_3002 ()
#13 0x00000000005feb39 in camlCamlinternalLazy__force_lazy_block_1010 () at camlinternalLazy.ml:25
#14 0x0000000000535870 in camlPrinttyp__best_type_path_1562 ()
#15 0x000000000053b0c3 in camlPrinttyp__type_same_name_2273 ()
#16 0x000000000053b133 in camlPrinttyp__trace_same_names_2278 ()
#17 0x000000000053b191 in camlPrinttyp__unification_error_2284 ()
#18 0x00000000004a3114 in camlMisc__try_finally_1011 ()
#19 0x00000000004a3114 in camlMisc__try_finally_1011 ()
#20 0x00000000004ab33c in camlLocation__error_of_printer_1172 ()
#21 0x00000000005819af in camlTypecore__fun_7581 ()
#22 0x00000000004a9d92 in camlLocation__loop_1153 ()
#23 0x00000000004ab54a in camlLocation__report_exception_rec_1184 ()
#24 0x000000000044adb5 in camlOptmain__main_1474 ()
#25 0x000000000044c31f in camlOptmain__entry ()
#26 0x0000000000446979 in caml_program ()
#27 0x0000000000636de6 in caml_start_program ()
#28 0x00000000006386d5 in __libc_csu_init ()
#29 0x0000003c2dc1ed5d in __libc_start_main () from /lib64/libc.so.6
#30 0x0000000000446059 in _start ()

File attachments

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 13, 2015

Comment author: @garrigue

Fixed in 4.02 and trunk at revisions 15916 and 15917.
Note that we do not want to disable visiting of all aliases, but just of aliases of persistent modules, which is a bit more complex.

The test case didn't repeat on the 4.02 branch, as we have switched to incremental computation of the environment. I have add a new test case, which forces the evaluation.
Should eventually add it to the test suite...

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 13, 2015

Comment author: @sliquister

Great, thank you! Didn't expect you'd be this quick to fix the problem.

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.