[m-rev.] for review: convert mode analysis to use var_tables

[Julien Fischer]

On Mon, 2 May 2022, Zoltan Somogyi wrote:

>
> 2022-05-02 11:28 GMT+10:00 "Zoltan Somogyi" <zoltan.somogyi at runbox.com>:
>>> Are these ZZZ comments something you intend to commit?
>>
>> Yes, but I will act on them and remove them before tonight.
>
> This diff does that. The only part worth reviewing is the new documentation
> in mode_info.m.

> diff --git a/compiler/mode_info.m b/compiler/mode_info.m
> index e42debab9..5f8e25bd1 100644
> --- a/compiler/mode_info.m
> +++ b/compiler/mode_info.m
> @@ -56,7 +56,7 @@
>                  unify_context,  % original source of the unification
>                  side            % LHS or RHS
>              )
> -    ;       mode_context_uninitialized.
> +    ;       mode_context_not_call_or_unify.
>
>      % Initialize a mode_context.
>      %
> @@ -426,7 +426,38 @@
>                  % The mode errors found.
>  /*  4 */        mi_errors                   :: list(mode_error_info),
> 
> -                % A description of where in the goal the error occurred.
> +                % Almost all mode errors are diagnosed when mode analysis
> +                % processes a unification or a call. To prepape for
> +                % the possibility of an error, before mode analysis
> +                % starts processing one side of a unification, it records
> +                % the identity of the side and of the unification in the
> +                % mode context, and likewise before it starts processing
> +                % the Nth argument of a call, we record N and the identity
> +                % of the call. If an error occurs, the code in mode_errors.m
> +                % that constructs the error message will pick up this context
> +                % from here.
> +                %
> +                % A few kinds of mode errors occur outside both unifications
> +                % and calls, and when processing HLDS constructs in which
> +                % such errors can occur, this field should contain
> +                % "mode_context_not_call_or_unify".
> +                %
> +                % When not processing a HLDS construct that is guaranteed
> +                % not to generate a mode error, the contents of this field
> +                % does not matter; it may be anything.
> +                %
> +                % When an error is discovered by code that is specific
> +                % to e.g. unifications, this field should not be needed;
> +                % the code should know in which part of which construct
> +                % it found the error. On the other hand, some errors
> +                % are caught by predicates that help process many kinds
> +                % of HLDS goals, and they need their caller to tell them
> +                % e.g. where the insts they handle come from. The reason
> +                % this field exists is probably because Fergus thought that
> +                % it is easier to stuff this information into the mode_info,
> +                % which those general-purpose predicates already got,

   *have* already got

That looks fine otherwise.

Julien.