[m-rev.] for review: record typechecking results in var_tables

[Julien Fischer]

On Sat, 28 May 2022, Zoltan Somogyi wrote:

> Record typechecking results in var_tables.
> 
> compiler/hlds_clauses.m:
>     The clauses_info type used to have two fields whose type is "vartypes".
>     One contained type information we knew before typechecking, e.g. from
>     explicit "Var : type" annotations, while the other contained the
>     *results* of typechecking. Keep the former, but replace the latter
>     with a var_table.
>
>     Allow compiler passes that construct clauses to fill in the first field
>     with the types of the head variables, because for the clauses of some
>     kinds of predicates (such as predicates implementing builtins) that are
>     "constructed correct" and do not need typechecking, this is all we need.
>
>     Put the fields of clauses_info that deal with variables and their types
>     next to each other, in the order in which they are filled in.
> 
> compiler/add_clause.m:
>     Don't construct the context pieces needed for parsing mode annotations
>     on arguments in the clause head unless the clause head's arguments
>     *have* mode annotation, which they virtually never do.

s/annotation/annotations/

...

> diff --git a/compiler/hlds_clauses.m b/compiler/hlds_clauses.m
> index d04546710..75bb1199c 100644
> --- a/compiler/hlds_clauses.m
> +++ b/compiler/hlds_clauses.m

...


> @@ -51,21 +53,92 @@
>      %
>  :- type clauses_info
>      --->    clauses_info(
> -                % The varset describing the clauses.
> +                % The varset describing the clauses seen so far.
> +                % Each new clause has its own varset merged into this one,
> +                % with the variables in the clause being renamed accordingly.
> +                %
> +                % The typechecker uses this varset as the source of information
> +                % about variable names for use in any error messages
> +                % it generates, and when it is done, it merges the variable
> +                % names from this field with the variable types it infers,
> +                % and records the result in the cli_var_table field.
> +                % All compiler passes after typechecking should use that field
> +                % as the source of information about both the names and the
> +                % types of the predicate's variables.
> +                %
> +                % There is one part of the compiler, the part that creates
> +                % HLDS dumps, that both
> +                % - needs both variable name and type information, and
> +                % - is invoked both before and after typechecking.
> +                % Before typechecking, it should use the cli_varset and
> +                % cli_explicit_vartypes fields, while after typechecking,
> +                % it should use the cli_var_table field, so it needs a way
> +                % to distinguish these two situations.
> +                %
> +                % Passing that code a before/after typechecking flag would
> +                % work, but would prevent doing typechecking lazily, on demand,
> +                % after the main typechecking pass is done, in the case of
> +                % opt-imported predicates for which, at the time of the main
> +                % typechecking pass, the compiler does not know whether they
> +                % are used or not.
> +                %
> +                % We could add an extra field here just to steer
> +                % hlds_out_pred.m one way or the other, but this would increase
> +                % memory use.
> +                %
> +                % Instead, we tell hlds_out_pred.m to use the cli_var_table
> +                % field by having the post-typecheck pass reset the
> +                % cli_varset field to empty. (In the rare case of a predicate
> +                % that has no variables at all, it does not matter where
> +                % hlds_out_pred.m gets the names of the variables from.)
> +                % The typechecking pass itself cannot easily do this,
> +                % because in the presence of type inference and its iteration
> +                % to a fixpoint,
> +                %
> +                % 1 when we finish typechecking a predicate, we don't know
> +                %   whether we will need to typecheck the predicate again,
> +                %   so there no is *obviously last* typecheck of a predicate

    ... there is no ...

The rest looks fine.

Julien.