| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000489 | mercury | Bug | public | 2020-01-09 14:31 | 2020-01-15 19:54 | ||||
| Reporter | wangp | ||||||||
| Assigned To | wangp | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0000489: mmc --make gets confused by source files with same name as standard library module | ||||||||
| Description | mmc --make gets confused by a source file in the current directory that matches the name of a standard library module, e.g. in the attached test case, lexer.m contains the sub-module `test.lexer'. Test 1 - tries to make lexer.mih from lexer.m --------------------------------------------- % mmc -s hlc.gc -m test -v Making Mercury/mihs/lexer.mih Invoking self `mmc [...] lexer' <-- not test.lexer ... lexer.m:010: In module `lexer': error: lexer.m:010: the absence of an `:- import_module' or `:- use_module' lexer.m:010: declaration for `test' prevents access to the `:- import_module' lexer.m:010: declaration for its child module `test.other'. Test 2 - likewise for .opt files -------------------------------- % mmc -s asm_fast.gc --intermod-opt -m test Making Mercury/opts/test.opt Making Mercury/opts/test.lexer.opt Making Mercury/opts/test.other.opt Making Mercury/opts/lexer.opt lexer.m:010: In module `lexer': error: lexer.m:010: the absence of an `:- import_module' or `:- use_module' lexer.m:010: declaration for `test' prevents access to the `:- import_module' lexer.m:010: declaration for its child module `test.other'. ** Error making `Mercury/opts/lexer.opt'. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
wangp (developer) 2020-01-09 16:23 |
Notes: do_get_module_dependencies assumes the SourceFileName returned by module_name_to_file_name can only be the source file for the given ModuleName, so the solution may require reading the `:- module` item before proceeding with make_module_dependencies. If a source file map is present, it may be helpful to rule out the default source file name: if "lexer.m" is mapped to `test.lexer' then it cannot be the source file for module `lexer'. |
|
zs (developer) 2020-01-09 21:18 |
The documentation of the -f option states: "Output the module name to file name mapping for the list of source files given as non-option arguments to ‘mmc’ to Mercury.modules. This must be done before ‘mmc --generate-dependencies’ if there are any modules for which the file name does not match the module name. If there are no such modules the mapping need not be generated." So if there is NO source file map present, mmc --make is *allowed* to assume that lexer.m contains a module named "lexer", and *not* a module named "test.lexer". The error message it generates could of course be improved, e.g. by drawing attention to this fact, but in this case, I don't think the compiler is confused; more like it is misled, which is not its fault. Or am I missing something? |
|
wangp (developer) 2020-01-09 21:53 |
The section on separate sub-modules states: "For a module named ‘foo.bar.baz’, The University of Melbourne Mercury implementation requires the source to be located in a file named foo.bar.baz.m, bar.baz.m, or baz.m." |
|
zs (developer) 2020-01-11 18:57 |
We have two endpoints of a spectrum where the answer to the question "should you have to run mmc -f *.m?" is clear-cut. Endpoint A: every module is in a file whose name is the fully qualified module name. Endpoint B: every module is a file whose name has no relationship to the module name. It is clear that at Endpoint A, the answer is "no", while at endpoint B, it is "yes". At the moment, the answer is also "no" if every module is in a file whose name is either the fully qualified module name *or a subsequence* of the fully qualified sequence. The code that implements that check, in read_first_module_decl in parse_module.m, already has an XXX, on code that accepts module A.B.C not just as being in file A.C.m, but also as being in file A.D.B.C.m. And your bug report demonstrates another problem with the existing code. There are two ways to fix this bug. One is to change this code to require the expected module name and the actual module name to be identical. Without mmc -f, this would mean that the answer is "yes" everywhere except at Endpoint A. This would be a change from the current situation, and would require a change in the manual, but the rule would be simple and easy to obey: always use mmc -f. The other possible approach to the fix, which I read your initial note as supporting, would require the compiler to look for a known module name (test.lexer) in one file name after another (all being subsequences of the fully qualified module name) until it found one whose :- module declaration had the looked-for name. (In this case, we would need to look in just two places, test.lexer.m and lexer.m, but in general, the list could be a lot longer). In effect, this approach would require mmc --generate-dependencies to do a significant part of the job of mmc -f. I, for one, would find that solution more complex than necessary, from the user's point of view as well as from an implementor's. |
|
wangp (developer) 2020-01-12 12:08 |
The current rules have always seemed oddly lax to me, and I think most larger Mercury project would be using mmc -f for one reason or another, so I have no problem with changing the compiler's behaviour such that modules must be in a file whose names is the fully qualified module name (.m), or else listed in the source file map. |
|
zs (developer) 2020-01-12 12:14 |
In that case, I will post a proposed diff for doing this later today. I also propose that this change be part of 20.01. Any objections? |
|
juliensf (administrator) 2020-01-12 12:55 |
There are definitely some larger Mercury projects that do *not* use mmc -f; Opturion's runtime library is an example. That's not an objection since the fix is trivial, but the proposed change is going to break some things. No objections to including this in 20.01 for me. |
|
zs (developer) 2020-01-12 22:28 |
Fix committed 2020 jan 12. |
|
wangp (developer) 2020-01-13 10:49 |
A file listed in the source file map needs to be not returned as the source file for some different module. (assigning to self; Mantis only has a "Request feedback" button) |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-01-09 14:31 | wangp | New Issue | |
| 2020-01-09 14:31 | wangp | File Added: mmc_make_source_filename_confusion.tar.gz | |
| 2020-01-09 16:23 | wangp | Note Added: 0001056 | |
| 2020-01-09 21:18 | zs | Note Added: 0001057 | |
| 2020-01-09 21:53 | wangp | Note Added: 0001058 | |
| 2020-01-11 18:57 | zs | Note Added: 0001059 | |
| 2020-01-12 12:08 | wangp | Note Added: 0001060 | |
| 2020-01-12 12:14 | zs | Note Added: 0001061 | |
| 2020-01-12 12:55 | juliensf | Note Added: 0001062 | |
| 2020-01-12 22:28 | zs | Assigned To | => zs |
| 2020-01-12 22:28 | zs | Status | new => resolved |
| 2020-01-12 22:28 | zs | Resolution | open => fixed |
| 2020-01-12 22:28 | zs | Note Added: 0001063 | |
| 2020-01-13 10:49 | wangp | Assigned To | zs => wangp |
| 2020-01-13 10:49 | wangp | Status | resolved => feedback |
| 2020-01-13 10:49 | wangp | Resolution | fixed => reopened |
| 2020-01-13 10:49 | wangp | Note Added: 0001064 | |
| 2020-01-15 19:54 | wangp | Status | feedback => resolved |
| 2020-01-15 19:54 | wangp | Resolution | reopened => fixed |
| Issue History |