[m-rev.] for post-commit review: allow some colors to be left unspecified

[Zoltan Somogyi]

For review by Peter. I have tested this by temporarily removing
one of the colors from the value set for MERCURY_COLOR_SCHEME
by tools/bootcheck, and it works.

The informational message we now generate for a missing color
is now ignored. What I intend to do with it is as follows.

- When we get such a message, we record it in a mutable in write_error_spec.m.

- When write_error_spec.m writes out any error_spec, it records that fact in
  another mutable.

- The compiler invokes maybe_print_delayed_error_messages when it is
  about to exit. It usually prints the message about specifying -E to get
  verbose errors. It would now also print the informational message
  about colors left unspecified if (a) such a message exists, and (b)
  some error_spec *was* printed.

This would add the informational message to the output of a
compiler invocation only when that output could have been affected
by the color being left unspecified.

I could go even further and have write_error_spec.m record which
color names are referred to in the pieces it writes out, and print
the informational message only if the intersection of the
color names used by the written error_specs and the color names
left unspecified is nonempy. However, I think that would be
overkill.

Do you guys agree with my proposed course of action?
I would prefer to deal with any objections before I implement
that course, rather than after.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.cus
Type: application/octet-stream
Size: 1043 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20240606/48750aa8/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.cus
Type: application/octet-stream
Size: 18563 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20240606/48750aa8/attachment-0003.obj>