| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0000584 | mercury | Bug | public | 2026-04-02 12:18 | 2026-04-02 17:23 | ||||||||
| Reporter | wangp | ||||||||||||
| Assigned To | |||||||||||||
| Priority | normal | Severity | crash | Reproducibility | always | ||||||||
| Status | new | Resolution | open | ||||||||||
| Product Version | |||||||||||||
| Target Version | Fixed in Version | ||||||||||||
| Summary | 0000584: exception in high-level code generator when type referenced via import in parent module | ||||||||||||
| Description | The compiler crashes in the MLDS backend on the attached test case, where mod_a.sub1 references a type in a sibling module, relying on a import_module declaration in the parent module for visibility of that type. % mmc -s hlc.gc -m bugmain.all_cs Making Mercury/int3s/bugmain.int3 Making Mercury/int3s/mod_a.int3 Making Mercury/int3s/mod_a.sub2.int3 Making Mercury/int3s/mod_a.sub1.int3 Making Mercury/int0s/mod_a.int0 Making Mercury/ints/mod_a.sub2.int Making Mercury/ints/mod_a.sub1.int Making Mercury/ints/mod_a.int Making Mercury/ints/bugmain.int Making Mercury/cs/bugmain.c Uncaught Mercury exception: Software Error: map.lookup: key not found Key Type: string Key Value: "bbb" Value Type: tree234.tree234(parse_tree.prog_data.type_ctor, hlds.hlds_data.hlds_type_defn) Stack dump follows: 0 pred exception.throw/1-0 (erroneous) (exception.m:312) 1 pred require.error/1-0 (erroneous) (require.m:173) 2 pred require.report_lookup_error/3-0 (erroneous) (require.m:277) 3 pred map.lookup/3-0 (det) (map.m:1463) 4 pred hlds.hlds_data.lookup_type_ctor_defn/3-0 (det) (hlds_data.m:598) 5 func hlds.type_util.classify_type_ctor/2-0 (det) (type_util.m:1095) 6 func ml_backend.mlds.mercury_type_to_mlds_type/2-0 (det) (mlds.m:2870) 7 pred ml_backend.ml_code_util.ml_gen_local_var_decl/6-0 (det) (ml_code_util.m:956) 8 pred ml_backend.ml_code_gen.ml_gen_local_var_decls/6-0 (det) (ml_code_gen.m:1393) 9 pred ml_backend.ml_code_gen.ml_gen_goal/7-0 (det) (ml_code_gen.m:611) 10 pred ml_backend.ml_proc_gen.ml_gen_proc_body/10-0 (det) (ml_proc_gen.m:1701) 11 pred ml_backend.ml_proc_gen.ml_gen_proc/12-0 (det) (ml_proc_gen.m:630) 12 pred list.foldl3/8-0 (det) (list.m:4236) 13 pred ml_backend.ml_proc_gen.ml_gen_scc_code/11-0 (det) (ml_proc_gen.m:328) 14 pred ml_backend.ml_proc_gen.ml_gen_scc/13-0 (det) (ml_proc_gen.m:233) 15 pred ml_backend.ml_proc_gen.ml_gen_sccs/13-0 (det) (ml_proc_gen.m:217) 16 pred ml_backend.ml_proc_gen.ml_gen_preds/10-0 (det) (ml_proc_gen.m:123) 17 pred ml_backend.ml_top_gen.ml_code_gen/7-0 (det) (ml_top_gen.m:85) 18 pred top_level.mercury_compile_mlds_back_end.hlds_to_mlds/9-0 (det) (mercury_compile_mlds_back_end.m:133) 19 pred top_level.mercury_compile_augment.choose_and_execute_backend_passes/15-0 (det) (mercury_compile_augment.m:479) 20 pred top_level.mercury_compile_augment.after_front_end_passes/14-0 (det) (mercury_compile_augment.m:412) 21 pred top_level.mercury_compile_augment.process_augmented_module/16-0 (det) (mercury_compile_augment.m:283) 22 pred top_level.mercury_compile_augment.augment_and_process_module/14-0 (det) (mercury_compile_augment.m:209) 23 pred list.map_foldl3/9-0 (det) (list.m:4575) 24 pred top_level.mercury_compile_augment.augment_and_process_all_submodules/15-0 (det) (mercury_compile_augment.m:158) 25 pred top_level.mercury_compile_augment.augment_and_process_source_file/17-0 (det) (mercury_compile_augment.m:136) 26 pred top_level.mercury_compile_main.read_augment_and_process_module/15-0 (det) (mercury_compile_main.m:1150) 27 pred top_level.mercury_compile_main.do_process_compiler_arg/13-0 (det) (mercury_compile_main.m:788) 28 pred top_level.mercury_compile_main.do_process_compiler_cmd_line_args/15-0 (det) (mercury_compile_main.m:606) 29 pred top_level.mercury_compile_main.do_op_mode_args/13-0 (det) (mercury_compile_main.m:418) 30 pred top_level.mercury_compile_main.do_op_mode/11-0 (det) (mercury_compile_main.m:236) 31 pred top_level.mercury_compile_main.main_after_setup/6-0 (det) (mercury_compile_main.m:191) 32 pred top_level.mercury_compile_main.main_for_make/6-0 (det) (mercury_compile_main.m:147) 33 pred make.module_target.call_mercury_compile_main/7-0 (det) (make.module_target.m:613) 34 pred libs.process_util.call_child_process_io_pred/4-0 (det) (process_util.m:458) reached unknown label ** Error making `Mercury/cs/bugmain.c'. % mdb mmc -s hlc.gc -C bugmain --use-subdirs Melbourne Mercury Debugger, mdb version DEV. Copyright 1998-2012 The University of Melbourne. Copyright 2013-2026 The Mercury team. mdb is free software; there is absolutely no warranty for mdb. 1: 1 1 CALL pred mercury_compile.main/2-0 (det) mercury_compile.m:31 mdb> e 697392: 243564 32 EXCP pred map.lookup/3-0 (det) e;c2; map.m:1463 (hlds_data.m:598) mdb> P Map (arg 1) three("float_box", two(type_ctor(qualified(unqualified("private_builtin"), "float_box"), 0), hlds_type_defn/9, empty, empty), "struct", two/4, three/7, three/7, three/7) K (arg 2) "bbb" | ||||||||||||
| Tags | No tags attached. | ||||||||||||
| Attached Files |
| ||||||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
zs (developer) 2026-04-02 17:23 |
I see two issues with the test case. The less important one is that mod_a.m has an import but contains nothing that could actually use that import. I think this should be an at least a warning and preferably an error. I know that imports in parent modules are effective in their child modules, but we agreed years ago that child modules should do their own imports (since that way, the children that do not need a specific import can simply skip it). However, this is an aside, since if mod_a.m did contain something that used that import, the problem would still exist. The second issue is that mod_a.sub1.m, which is a *public* submodule of mod_a and can therefore be imported by modules outside mod_a, refers in its interface to a type, bbb, which is defined in mod_a.sub2, which is a *private* submodule of mod_a. This contradiction means that if we want the test program to compile correctly as it is, the only way to do so would be to break the privacy of mod_a.sub2.m. I think it would be both more consistent and more understandable for user if we simply generated an error for the reference to bbb in mod_a.sub1.m when generating its .int file. Note that doing that would not in itself fix the problem, because the crash also occurs if we move the include of sub2 to the interface of mod_a.m. This is because mod_a.sub1.int refers to mod_a.sub2.bbb, but does not import mod_a.sub2. This is caused by mod_a.sub1.m not itself importing sub2. Fixing this by adding such an import to mod_a.sub1.int should not be difficult. However, that added import would be problematic without a fix for the second issue above, because it would allow modules importing mod_a.sub1 to see things in mod_a.sub2 that they are not supposed to be able to see. |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-04-02 12:18 | wangp | New Issue | |
| 2026-04-02 12:18 | wangp | File Added: testcase.tar.gz | |
| 2026-04-02 17:23 | zs | Note Added: 0001248 | |
| Issue History |