[m-rev.] for review: return blocking diagnostics from grab_modules.m

[Julien Fischer]

On Sun, 5 Apr 2026 at 21:09, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:

> Replace error flags with the list of errors themselves.
>
> This is another move towards making it impossible for the compiler
> to stop due to the presence of an error *without* printing a diagnostic
> about that error.
>
> compiler/grab_modules.m:
>     Some of the errors that this module are intended to block the compiler
>     from continuing on to semantic analysis, and some are not. We used
>     to make the distinction by returning a flag saying "some of these
>     are blocking errors", but the list of diagnostics that contained
>     these blocking errors
>
>     - contained a list of error_specs reporting *both* kinds of errors, and
>     - was not returned alongside the flag, but instead hidden inside
>       the module baggage, making it hard to find, and easy to ignore.
>
>     Change this to computing two lists of error_specs: one for blocking errors,
>     and one for nonblocking ones. Return the former explicitly, keeping the
>     latter in the baggage. This design lets the code that stops execution
>     before semantic analysis to test for the list of blocking errors
>     being non-empty, which makes printing them the easy thing to do.
>
>     Delete the code that, with --very-verbose, wrote out any error_specs
>     we generated during the processing of a .opt or .trans_opt file
>     immediately after that processing. The reason is that
>
>     - if we print those error_specs out and then do not return them
>       to mercury_compile_make_hlds.m, then mercury_compile_make_hlds.m
>       will be making decisions on incomplete and therefore incorrect data,
>       while
>
>     - if we print those error_specs out and *also* return them, then
>
>       - either those diagnostics will be printed twice, or
>       - we need to implement a new system whereby write_error_spec.m
>         keeps a database of the diagnostics it has already printed,
>         and simply skips printing any repeats.
>
>     Neither of those alternative is palatable, and since in several
>     decades, I have never needed such immediate printing of diagnostics,
>     losing that capability is not really an issue.
>
>     Fix some relics of the era when the data structures that were
>     module_baggage's predecessors could not distinguish between fatal
>     and nonfatal errors.
>
> compiler/mercury_compile_make_hlds.m:
>     For now, make the new code in grab_modules.m work with the existing
>     decision making code. Changing that is future work, since it requires
>     changes to other compiler components as well.

That's fine.

Julien.