mirror of
https://github.com/Mercury-Language/mercury.git
synced 2026-04-18 10:53:40 +00:00
7d11ba1e5c
Type specialization pragmas allow the procedure to be specialized
to be specified either as a sym_name/arity pair, or as a sym_name
followed by a list of argument modes. In both cases, the sym_name
is implicitly qualified with the name of the current module.
The problem that this diff fixes arose when the type_spec pragma
specified the procedure as a sym_name/arity pair, but the sym_name
had a qualification that is inconsistent with the current module.
The code for parsing such pragmas should report this qualification
inconsistency, but the old code did not do that. Instead, it took
the failure of the attempt to parse the sym_name/arity pair as a
*properly qualified* sym_name pair to mean that the procedure specification
must be a sym_name applied to argument modes, and as a consequence,
generated a report that said "In the first argument `:- pragma type_spec'
declaration: error: `1' is not a valid inst", which definitely violates
the law of least astonishment.
The fix is to commit to interpreting a procedure specification
as a sym_name/arity pair as soon as we see that the relevant term
has this structure, and report any problem during the implicit qualification
of the sym_name using an error message appropriate to that commitment.
compiler/parse_util.m:
Delete parse_implicitly_qualified_name_and_arity, because it inherently
does not allow the failure of implicitly module qualifying of a sym_name
to be treated differently from the failure to parse a term as a sym_name
and arity pair. This deletion thus requires all its callers to handle
the implicit qualification themselves.
Rename the parse_unqualified_name_and_arity predicate, which does the
initial part of the job of the deleted predicate, to just
parse_sym_name_and_arity, because the sym_name it returns may in fact
be qualified in the input data; the predicate just doesn't *force* it
to be qualified.
compiler/parse_pragma.m:
compiler/parse_type_defn.m:
Replace calls to the deleted predicate with code that explicitly does
implicit qualification of the symbol name in sym_name/arity pairs.
compiler/parse_sym_name.m:
When implicitly module qualifying sym_names fails, replace the word
"definition" in the error message with the sym_name itself, since
the sym_name does not HAVE to be the name of something being defined.
In the two test cases affected by this diff, they are in fact a type_spec
pragma, and an include_module declaration.
In another pair of cases, change the wording of some error messages
to match our usual phraseology. Those error messages are apparently
not tested by any test case.
compiler/parse_inst_mode_defn.m:
compiler/parse_pragma_foreign.m:
compiler/parse_type_repn.m:
compiler/recompilation.used_file.m:
Conform to the rename above.
tests/invalid/type_spec.{m,err_exp}:
Extend this existing test case with an incorrectly module-qualified
procedure name in a type_spec declaration.
tests/invalid_nodepend/bad_include.err_exp:
Expect the updated wording of the error message about an incorrectly
module-qualified include declaration.
7 lines
412 B
Plaintext
7 lines
412 B
Plaintext
bad_include.m:017: Error: symbol name expected at 42.
|
|
bad_include.m:018: Error: symbol name expected at f([1, 2, 3]).
|
|
bad_include.m:019: Error: the module qualifier in `bad_include.sub1.sub2' does
|
|
bad_include.m:019: not match the preceding `:- module' declaration.
|
|
bad_include.m:020: Error: the module qualifier in `other_module.sub3' does not
|
|
bad_include.m:020: match the preceding `:- module' declaration.
|