compiler/typecheck_errors.m:
When we report a mismatch between the actual and expected types,
we print both types. When both these types are big, doing a "visual diff"
between the two can be hard, which is why, for a while now, we have had
code to print the diffs between the two types. However, the code computing
this diff had a bug. It detected and reported situations in which the
actual and expected types had, in the same position, the same type
constructor name but with two different arities, but ignored situations
in the type constructed differed in their names, which is a much more
common problem. Fix this.
When we report a mismatch between the actual and expected types,
we print the types themselves colored incorrect and correct respectively.
But when we diagnosed the sources of the difference, we printed
only the report of the mismatch using the incorrect color, and printed
the mismatched actual and expected entities using the "inconsistent" color.
Fix this.
compiler/typecheck_error_type_assign.m:
When the difference between actual and expected types occurs even when
builtin qualifiers have been stripped type names in both, record the
types so stripped not just in the format_pieces representations of the
types, but the types themselves. This avoids the need for new code
in typecheck_errors.m to consider the same issue.
compiler/error_spec.m:
Minor improvements in comments.
tests/invalid/actual_expected.err_exp:
tests/invalid/arith_wrong_module.err_exp:
tests/invalid/bug197.err_exp:
tests/invalid/ext_type_bug.err_exp:
tests/invalid/fbnf.err_exp:
tests/invalid/higher_order_mode_mismatch.err_exp:
tests/invalid/type_diff.err_exp:
tests/invalid_purity/impure_pred_t1_fixed.err_exp:
tests/invalid_purity/impure_pred_t2.err_exp:
tests/invalid_purity/purity_nonsense_1.err_exp:
tests/invalid_purity/purity_nonsense_2.err_exp:
Expect updated diagnostics.
compiler/det_analysis.m:
compiler/post_typecheck.m:
compiler/typecheck_errors.m:
Use color more sparingly. Improve wording.
compiler/error_spec.m:
Add two new utility functions for coloring lists of items, and
add a new kind of piece, purity_desc_article. Both are for use by
new code in the modules above.
compiler/write_error_spec.m:
Implement the new kind of piece.
tests/invalid/arg_permutation.err_exp:
tests/invalid/arith_wrong_module.err_exp:
tests/invalid/bad_sv_unify_msg.err_exp:
tests/invalid/bug184.err_exp:
tests/invalid/bug197.err_exp:
tests/invalid/bug214.err_exp:
tests/invalid/bug257.err_exp:
tests/invalid/coerce_void.err_exp:
tests/invalid/fbnf.err_exp:
tests/invalid/freefree.err_exp:
tests/invalid/getopt_old.err_exp:
tests/invalid/higher_order_mode_mismatch.err_exp:
tests/invalid/integral_constant_no_suffix.err_exp:
tests/invalid/one_member.err_exp:
tests/invalid/pragma_c_code_no_det.err_exp:
tests/invalid/type_diff.err_exp:
tests/invalid/typeclass_test_8.err_exp:
tests/invalid/unsatisfiable_constraint.err_exp:
tests/invalid_purity/impure_pred_t1_fixed.err_exp:
tests/invalid_purity/impure_pred_t2.err_exp:
tests/invalid_purity/purity_nonsense_1.err_exp:
tests/invalid_purity/purity_nonsense_2.err_exp:
tests/warnings/singleton_test.err_exp:
Expect updated diagnostics.
compiler/error_spec.m:
Add a new color name, color_subject, which is intended to be used
as the color for the subject of an error message. The subject is
usually a variable or a term.
compiler/options.m:
doc/user_guide.texi:
Add an option to control the actual color for this color name.
compiler/globals.m:
Include the new color in the color specification database.
compiler/write_error_spec.m:
Handle the conversion of the new color name to the selected
corresponding actual color.
compiler/typecheck_errors.m:
Color the subjects of (most of) the error messages generated by
this module with the new color.
tests/invalid/abstract_eqv.err_exp:
tests/invalid/actual_expected.err_exp:
tests/invalid/actual_more_expected.err_exp:
tests/invalid/arg_permutation.err_exp:
tests/invalid/arith_wrong_module.err_exp:
tests/invalid/bad_statevar_bad_context.err_exp:
tests/invalid/bug197.err_exp:
tests/invalid/coerce_infer.err_exp:
tests/invalid/coerce_non_du.err_exp:
tests/invalid/coerce_type_error.err_exp:
tests/invalid/coerce_unify_tvars.err_exp:
tests/invalid/comparison.err_exp:
tests/invalid/error_in_list.err_exp:
tests/invalid/exist_foreign_error.err_exp:
tests/invalid/ext_type.err_exp:
tests/invalid/ext_type_bug.err_exp:
tests/invalid/fbnf.err_exp:
tests/invalid/foreign_procs_exist_type.err_exp:
tests/invalid/getopt_old.err_exp:
tests/invalid/higher_order_mode_mismatch.err_exp:
tests/invalid/ho_type_arity_bug.err_exp:
tests/invalid/illtyped_compare.err_exp:
tests/invalid/integral_constant_no_suffix.err_exp:
tests/invalid/method_impl.err_exp:
tests/invalid/mixed_up_streams.err_exp:
tests/invalid/mpj1.err_exp:
tests/invalid/mpj4.err_exp:
tests/invalid/no_method.err_exp:
tests/invalid/nullary_ho_func_error.err_exp:
tests/invalid/overloading.err_exp:
tests/invalid/record_syntax_errors.err_exp:
tests/invalid/try_bad_params.err_exp:
tests/invalid/type_diff.err_exp:
tests/invalid/type_error_ambiguous.err_exp:
tests/invalid/type_error_in_arg.err_exp:
tests/invalid/type_mismatch.err_exp:
tests/invalid/types2.err_exp:
tests/invalid/user_field_access_decl_override2.err_exp:
tests/invalid_nodepend/errors2.err_exp:
tests/invalid_purity/impure_func_t5.err_exp:
tests/invalid_purity/impure_pred_t1.err_exp:
tests/invalid_purity/impure_pred_t1_fixed.err_exp:
tests/invalid_purity/impure_pred_t2.err_exp:
tests/invalid_purity/purity_nonsense.err_exp:
tests/invalid_purity/purity_nonsense2.err_exp:
tests/invalid_purity/purity_type_error.err_exp:
Expect the new-colored output.
compiler/typecheck_errors.m:
Add colors to the parts of diagnostics that contrast incorrect type
with the expected correct types, and the parts that document possible
causes.
compiler/error_spec.m:
Add some utility functions needed by the above.
compiler/write_error_spec.m:
Fix several issues revealed by the effect of the above changes
on the outputs we generate for invalid test cases.
Issue one. We had a sanity check that, after joining two lines,
checked whether the sum of the recorded line lengths matched
the number of code points in the joined string. Delete this check,
because it does the wrong thing in the presence of color changes.
The reason is that the recorded lengths consider the escape sequences
implementing them to be zero length (since they occupy zero columns),
but string.count_code_points counts them anyway.
Issue two. We used to handle colors in each paragraph separately,
effectively starting each paragraph with an empty color stack.
This caused problems with messages in which a color change is supposed
to affect several lines *that have explicit newlines between them*,
since the code puts paragraph breaks after each explicit newline.
Fix this by setting the initial color stack of each nonfirst
paragraph to the final color stack of the previous paragraph.
Issue three. It is possible for an unbreakable string (such as the name
of a predicate) that is too long to fit in the space available on a line.
We have to include such strings in a line despite the violation of the
length limit. Previously, we had to do only when the string was the first
thing on the line. Now, it is possible for such a string to be preceded
by one or more color changes, which occupy zero columns. Include
too-long-to-fit unbreakable strings on the line in such cases as well.
Issue four. Some callers of the color_pieces functions pass them
piece lists that end in newlines. In such cases, we don't want
the color reset to take place at the start of the next line after the
colored pieces, because that makes the output harder to check visually
for correctness in .err_exp files. In such cases, swap the order
of the color_end and newline pieces. (Since newlines cannot be colored,
this has no semantic effect.)
Issue five. If a line either started out colored or contained pieces
that started a new color, we marked it to be followed by a color reset
when it is printed. However, if the color was already reset by pieces
that are also contained in the line, so that the color stack was empty
at the end of the line, then this final additional reset was redundant.
Arrange not to print such redundant resets, also in the interest of
making .err_exp files easier to check.
Improve the debugging infrastructure a bit.
Don't duplicate blank lines zero times.
tests/invalid/Mmakefile:
tests/invalid_nodepend/Mmakefile:
tests/invalid_purity/Mmakefile:
tests/warnings/Mmakefile:
Enable color diagnostics in these test directories.
tests/invalid/abstract_eqv.err_exp:
tests/invalid/actual_expected.err_exp:
tests/invalid/actual_more_expected.err_exp:
tests/invalid/arith_wrong_module.err_exp:
tests/invalid/bug197.err_exp:
tests/invalid/error_in_list.err_exp:
tests/invalid/ext_type.err_exp:
tests/invalid/ext_type_bug.err_exp:
tests/invalid/fbnf.err_exp:
tests/invalid/foreign_procs_exist_type.err_exp:
tests/invalid/getopt_old.err_exp:
tests/invalid/higher_order_mode_mismatch.err_exp:
tests/invalid/ho_type_arity_bug.err_exp:
tests/invalid/integral_constant_no_suffix.err_exp:
tests/invalid/method_impl.err_exp:
tests/invalid/mixed_up_streams.err_exp:
tests/invalid/mpj1.err_exp:
tests/invalid/mpj4.err_exp:
tests/invalid/no_method.err_exp:
tests/invalid/nullary_ho_func_error.err_exp:
tests/invalid/overloading.err_exp:
tests/invalid/record_syntax_errors.err_exp:
tests/invalid/try_bad_params.err_exp:
tests/invalid/type_diff.err_exp:
tests/invalid/type_error_ambiguous.err_exp:
tests/invalid/type_error_in_arg.err_exp:
tests/invalid/type_mismatch.err_exp:
tests/invalid/types2.err_exp:
tests/invalid/user_field_access_decl_override2.err_exp:
tests/invalid_nodepend/errors2.err_exp:
tests/invalid_purity/impure_func_t5.err_exp:
tests/invalid_purity/impure_pred_t1.err_exp:
tests/invalid_purity/impure_pred_t1_fixed.err_exp:
tests/invalid_purity/impure_pred_t2.err_exp:
tests/invalid_purity/purity_nonsense.err_exp:
tests/invalid_purity/purity_nonsense2.err_exp:
tests/invalid_purity/purity_type_error.err_exp:
tests/warnings/inconsistent_pred_order.exp:
tests/warnings/subtype_order.exp:
Expect color in these expected output files.
compiler/typecheck_errors.m:
When we are reporting a type error in a var-functor unification
where the functor is the name of a function defined in library/int.m,
such as A = B - C or D = E + F, check whether
(a) the types of any of the variables involved in the error, *and*
(b) the expected argument or result types involved
are builtin integer types whose modules have NOT been imported.
If so, then add a note to the error message that points out
that operations on these type(s) require importing the corresponding
modules.
Do the same when reporting type errors in calls to predicates
whose name is the name of a predicate defined in library/int.m.
Fix an old ZZZ.
compiler/type_assign.m:
Fix typo in a (so far unused) field name.
tests/invalid/arith_wrong_module.{m,err_exp}:
A new test case with three errors, which respectively test the changes
to the three error-message-generating predicates modified by this diff.
tests/invalid/Mmakefile:
Enable the new test case.
