View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0000505 | mercury | Feature Request | public | 2020-05-01 16:46 | 2020-05-01 17:23 | ||||||||
Reporter | zs | ||||||||||||
Assigned To | zs | ||||||||||||
Priority | normal | Severity | minor | Reproducibility | have not tried | ||||||||
Status | assigned | Resolution | open | ||||||||||
Product Version | |||||||||||||
Target Version | Fixed in Version | ||||||||||||
Summary | 0000505: allow reference only to explicitly imported modules | ||||||||||||
Description | This one could be viewed as either a feature request or a bug fix, depending on perspective. Have the type and mode checkers generate an error if a predicate defined in the module being compiled has a reference to a type, inst, mode, predicate, function, or typeclass that is not defined in an *explicitly* imported module. The point is that the compiler implicitly imports some modules. For example, if the module being compiled contains a try/catch goal, we implicitly import the exception module, because our implementation of try/catch includes adding references to entities defined in that module. Currently, this means that such modules need not explicitly import exception even if the *rest* of the module makes references to entities defined in exception.m, because such references are satisfied by the implicit import. But this behavior looks inconsistent to users, since they don't know or care how try/catch is implemented, from their point of view, exception.m became available to the module being compiled as if magic. This access-as-if-by-magic can happen to some other modules that we can import implicitly, and even to user modules, which can be made available to the module being compiled if intermodule optimization is enabled via the int-for-opt mechanism, whereby we read the interface files of not-explicitly-imported modules because they are needed to allow type- and mode-checking of code included in .opt files. This is why the restriction would apply *only* when type- and mode-checking predicates defined in the module being compiled; applying it to code included from .opt files would defeat the purpose of reading int-for-opt files. | ||||||||||||
Tags | No tags attached. | ||||||||||||
Attached Files |
|