[m-rev.] for review: fix mantis bug #557

[Julien Fischer]

On Mon, 11 Apr 2022, Zoltan Somogyi wrote:

> Fix silent failure during module qualification.
> 
> This fixes Mantis bug #557.

...

> diff --git a/tests/hard_coded/bug557.m b/tests/hard_coded/bug557.m
> index e69de29bb..720e40c8d 100644
> --- a/tests/hard_coded/bug557.m
> +++ b/tests/hard_coded/bug557.m
> @@ -0,0 +1,50 @@
> +%-----------------------------------------------------------------------------%
> +% vim: ft=mercury ts=4 sw=4 t
> +%-----------------------------------------------------------------------------%
> +
> +:- module bug557.
> +
> +:- interface.
> +:- import_module io.
> +
> +:- type record
> +    --->    record(
> +                % This type is NOT ambiguous in the interface section
> +                % (because the only type named "ambiguous_type" available
> +                % in the interface is the one defined in this interface),
> +                % but it *would* be ambiguous in the implementation section
> +                % (because of the import of bug557_helper.ambiguous_type
> +                % there).
> +                %
> +                % Mantis bug #557 was caused by the fact that
> +                % module_qualify_type_ctor_checked_defn always module qualified
> +                % the checked definitions of types (such as record) as if
> +                % they were in the implementation section. This caused this
> +                % reference to ambiguous_type to set the "we found a type
> +                % that could not be uniquely qualified" flag. However,
> +                % module_qualify_type_ctor_checked_defn threw away the
> +                % error message generate for this, because it was about

s/generate/generated/

> +                % to module qualify the original type definitions from which
> +                % the checked type definition was constructed, and it did not
> +                % want duplicate error messages. However, the qualification
> +                % of the original type definition (this one) did not find
> +                % any ambiguity, and thus did not generate an error message.
> +                % The flag caused compilation to stop without further message
> +                % when it reached the frontend_pass predicate.
> +                ambiguous_type  :: ambiguous_type
> +            ).

That looks fine otherwise.

Julien.