This fixes an issue reported on m-users on sep 23, which was caused by
the compiler counting a type_info argument added by the polymorphism pass.
compiler/hlds_pred.m:
Add a field for recording the number of arguments added by the
polymorphism transformation. We could try to figure this out
by counting how many type_info and/or typeclass info args
the argument list contains as an initial subsequence,
and the compiler has code that does that, but this approach
is vulnerable if user code ever passes around e.g. type_infos
*explicitly*, which would be very unusual, but not impossible.
compiler/polymorphism.m:
Fill in this new field.
compiler/mode_errors.m:
Use the new field to fix the argument number in the error message.
(This seems to be the only mode error that makes such a reference.)
compiler/direct_arg_in_out.m:
Conform to the change in hlds_pred.m above.
compiler/mode_info.m:
Clarify some comments.
compiler/modes.m:
Fix indentation.
tests/invalid/mode_error_arg_number.{m,err_exp}:
The code in the original bug report, made into a new test case.
tests/invalid/Mmakefile:
Enable the new test case.
tests/invalid/bug278.err_exp:
tests/invalid/bug415.err_exp:
tests/invalid/merge_ground_any.err_exp:
Expect the correct argument number in these test cases. The old
expected argument numbers were wrong, which means that we had missed
at least three chances to find the bug that this diff fixes. The
wrong argument number was in merge_ground_any.err_exp at its creation
in 2001.
compiler/error_msg_inst.m:
Fix a bug that caused the suffix that all paths in two predicates
were supposed to add at the logical end of the constructed pieces
(though it could be followed by some punctuation) to *not* be added
to the constructed pieces on some paths. Since with our current approach,
the suffix for one inst in a list of insts can be the description
of *all the insts following it in the list*, this bug could delete
not just punctuation, but entire insts from the output. This did actually
happen for the invalid/html text case below.
Fix a problem that could cause each inst in a list of insts
to be indented one more level than the previous inst, which can be
very confusing.
Delete the comma from "instname, which expands to ...". When this output
occurs in an argument list, the presence of the comma can make it
harder to recognize where one argument ends and the next argument begins.
Factor out some common code.
Add an XXX noting a problem.
Fix documentation.
compiler/parse_tree_out_inst.m:
Provide two functions for use by error_msg_inst.m.
compiler/prog_mode.m:
Fix a comment.
tests/invalid/html.m:
Fix the description of the problem we are testing for.
tests/invalid/html.err_exp:
Expect the fix for the "omitted insts" bug above.
tests/invalid/bug117.err_exp:
tests/invalid/bug191.err_exp:
tests/invalid/bug415.err_exp:
tests/invalid/char_inst.err_exp:
tests/invalid/coerce_int.err_exp:
tests/invalid/constrained_poly_insts2.err_exp:
tests/invalid/ho_default_func_4.err_exp:
tests/invalid/merge_ground_any.err_exp:
tests/invalid/polymorphic_unification.err_exp:
Do not expect the deleted comma.
compiler/error_msg_inst.m:
When prettyprinting insts for use in error messages, we have to be careful
to generate finite output even for recursive insts. Previously, we did
the required check when processing user-defined inst names, but not when
processing compiler-generated inst names, which can also be recursive.
Fix this bug, which is Mantis bug 415.
Previously, we passed information about what potentially-recursive inst
names we have seen so far only downward. With the fix above, this avoids
infinite loops, but in some cases, it leads us to print the definition
of a given named inst more than once. Change our approach so that we
now pass information about the set of potentially-recursive inst names
we have seen sideways as well. This can make us generate more compact
and therefore more understandable output when prettyprinting insts that
contain such non-nested duplication.
When printing something that says "inst name x, which expands to ...",
indent the "..." one level deeper than the "inst name x". This visually
separates the thing being defined and its definition.
When prettyprinting complex insts, we show their structure using
indentation levels in the output. Each increase of indentation
should be balanced by a later matching decrease. Move the code that
does the increase and the decrease next to each other, to make it easier
to see the implicit correctness argument.
tests/invalid/bug415.{m,err_exp}:
A new test case for this bug.
tests/invalid/Mmakefile:
Enable the new test case.
tests/invalid/bug117.err_exp:
tests/invalid/bug191.err_exp:
tests/invalid/constrained_poly_insts2.err_exp:
tests/invalid/merge_ground_any.err_exp:
tests/invalid/polymorphic_unification.err_exp:
Expect the extra level of indentation after "which expands to".
tests/invalid/ho_default_func_4.err_exp:
Expect the extra level of indentation after "which expands to",
and expect a repeated inst name NOT to have its definition repeated.
