Mercury Bugs - mercury
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000584mercuryBugpublic2026-04-02 12:182026-04-02 17:23
Reporterwangp 
Assigned To 
PrioritynormalSeveritycrashReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000584: exception in high-level code generator when type referenced via import in parent module
DescriptionThe 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"

TagsNo tags attached.
Relationships
Attached Filesgz testcase.tar.gz (10,240) 2026-04-02 12:18
https://bugs.mercurylang.org/file_download.php?file_id=335&type=bug

Notes
(0001248)
zs   
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.

Issue History
Date ModifiedUsernameFieldChange
2026-04-02 12:18wangpNew Issue
2026-04-02 12:18wangpFile Added: testcase.tar.gz
2026-04-02 17:23zsNote Added: 0001248