2019-11-15 16:55 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000401mercuryBugpublic2019-08-04 09:39
Reporterwangp 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000401: different module import styles in interface and implementation
DescriptionIn the following test case the module does a `:- use_module' in the interface section, but also `:- import_module' of the same module in the implementation section.

% mmc -m int_impl_imports.err
int_impl_imports.m:004: In module `int_impl_imports':
int_impl_imports.m:004: warning: module `int_impl_imports_2' is imported in
int_impl_imports.m:004: the interface, but it is not used in the interface.
int_impl_imports.m:006: In definition of type `int_impl_imports.foo'/0:
int_impl_imports.m:006: error: undefined type `int_impl_imports_2.bar'/0.
int_impl_imports.m:006: (The module `int_impl_imports_2' has not been
int_impl_imports.m:006: imported in the interface.)

It worked up to at least rotd-2015-10-06 (which I happen to have installed).
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000872

zs (developer)

The bug is caused by process_module_long_interfaces in modules.m.
In int_impl_imports.m, the submodule int_impl_imports_2 is referenced twice:
it is used in the interface, and imported in the implementation.
grab_imported_modules process the import in the implementation first.
This reads the _2 module's .int file, and (since the import is NOT
in the interface) records that type bar is NOT available in the interface.
So far, so good. But when grab_imported_modules calls process_module_long_interfaces for the use in the interface,
it does not process the .int file again, since it has seen it before.

Not processing the .int file again is both right and wrong. Right because
it avoids double definitions, wrong because it leaves the incorrect permissions
for the type bar.

It is quote possible that earlier versions of Mercury got this right
only by accident.

~0000873

zs (developer)

I am now sure that 14.01 got this right only by accident.
It also processes int_impl_imports_2.int just once,
for the import_module in the implementation. Its just that
due to a bug, the effect of that import was to make the
imported module available in ALL of int_impl_imports.m,
not just its interface. I fixed that bug on nov 11 in
commit 0821b301f25241bc706a325d4ae0cb9c18dd250b.
The fix of THAT bug exposed THIS bug.

I am now working on a fix.

~0000875

zs (developer)

fix committed 2016 jan 11.

~0000876

wangp (developer)

There is still a problem with the fix committed.

In tests/valid_seq:

% mmake int_impl_imports.depend
% mmake int_impl_imports.int
mmc --make-interface --grade asm_fast.gc --flags ../TESTS_FLAGS int_impl_imports
int_impl_imports.m:004: In module `int_impl_imports':
int_impl_imports.m:004: warning: module `int_impl_imports_2' is imported in
int_impl_imports.m:004: the interface, but it is not used in the interface.
int_impl_imports.m:006: In definition of type `int_impl_imports.foo'/0:
int_impl_imports.m:006: error: undefined type `int_impl_imports_2.bar'/0.
int_impl_imports.m:006: (The module `int_impl_imports_2' has not been
int_impl_imports.m:006: imported in the interface.)
`int_impl_imports.int' not written.

~0001041

zs (developer)

Fix committed 2019 aug 3.
+Notes

-Issue History
Date Modified Username Field Change
2015-12-17 18:00 wangp New Issue
2015-12-17 18:00 wangp File Added: int_impl_imports.m
2015-12-17 18:01 wangp File Added: int_impl_imports_2.m
2015-12-17 18:54 zs Assigned To => zs
2015-12-17 18:54 zs Status new => assigned
2015-12-17 23:38 zs Note Added: 0000872
2015-12-18 15:20 zs Note Added: 0000873
2016-01-14 15:46 zs Note Added: 0000875
2016-01-14 15:46 zs Status assigned => resolved
2016-01-14 15:46 zs Resolution open => fixed
2016-01-18 20:11 wangp Note Added: 0000876
2016-01-18 20:11 wangp Status resolved => feedback
2016-01-18 20:11 wangp Resolution fixed => reopened
2019-08-04 09:39 zs Status feedback => resolved
2019-08-04 09:39 zs Resolution reopened => fixed
2019-08-04 09:39 zs Note Added: 0001041
+Issue History