[m-rev.] for post-commit review: diagnose bound inst vars

[Peter Wang]

On Wed, 30 Oct 2024 06:50:02 +0100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> Report mode errors for bound inst vars.
> 

> diff --git a/compiler/mode_errors.m b/compiler/mode_errors.m
> index 573e7833a..f59b82c82 100644
> --- a/compiler/mode_errors.m
> +++ b/compiler/mode_errors.m
> @@ -239,6 +247,36 @@
>      ;       match_cast
>      ;       match_event.
>  
> +:- type exact_or_not
> +    --->    eon_not_exact
> +    ;       eon_exact.
> +
> +:- type mode_mismatch
> +    --->    mode_mismatch(
> +                exact_or_not,
> +                % We check whether the current insts of the actual arguments
> +                % of a call match the required initial insts of the format

formal arguments

> +                % arguments of the callee by invoking either
> +                % modecheck_vars_are_live_no_exact_match (the usual case) or
> +                % modecheck_vars_are_live_exact_match.
> +                % This argument records which, with the intention being
> +                % that we can specialize find_satisfied_initial_insts_in_proc
> +                % to repeat the test that lead to the error *exactly*.

led

> +                % XXX We do not yet do this, so this field is unused.
> +
> +                list(mer_inst),
> +                % The required initial insts of the formal arguments.
> +
> +                set(inst_var)
> +                % If this set is not empty, then the actual arguments of the
> +                % call *do* match the required initial insts of the format

formal arguments

> +                % arguments, but the match binds the given set of inst_vars.
> +                % This is not allowed, because it would make the caller unable
> +                % to do its job if one or more of the given inst vars
> +                % has a value that is incompatible with the one that this
> +                % call binds it to.
> +            ).
> +
>  %---------------------%
>  
>  :- type pred_id_var_multimode_error

> @@ -1106,8 +1143,24 @@ mode_error_no_matching_mode_to_spec(ModeInfo, MatchWhat, InstMap, Vars,
>              [words("the input mode required for unifications."), nl]
>      ),
>  
> +    mode_info_get_instvarset(ModeInfo, InstVarSet),
> +    report_bound_inst_vars(InstVarSet, [HeadMismatch | TailMismatches], 1,
> +        BoundInstVarPieces0),
> +    (
> +        BoundInstVarPieces0 = [],
> +        BoundInstVarPieces = []
> +    ;
> +        BoundInstVarPieces0 = [_ | _],
> +        % XXX Should this addeddum be in a verbose_once message?
> +        BoundInstVarPieces = BoundInstVarPieces0 ++
> +            [words("(If a call binds an inst variable, then"),
> +            words("the caller loses the generality promised by"),
> +            words("its own mode declaration."), nl]
> +    ),

Missing closing parenthesis.

> @@ -413,39 +442,51 @@ create_var_var_unification(Var0, Var, Type, ModeInfo, Goal) :-
>  
>  %---------------------------------------------------------------------------%
>  
> -compute_arg_offset(PredInfo, ArgOffset) :-
> +:- type modecheck_arg_offset
> +    --->    modecheck_arg_offset(int).
> +
> +compute_pred_modecheck_arg_offset(PredInfo) = ArgOffset :-
>      pred_info_get_orig_arity(PredInfo, pred_form_arity(PredFormArityInt)),
>      pred_info_get_arg_types(PredInfo, ArgTypes),
>      % Note that this is not num_extra_args; it does the subtraction
>      % in the *other* direction.
>      list.length(ArgTypes, CurrentArity),
> -    ArgOffset = PredFormArityInt - CurrentArity.
> +    ArgOffset = modecheck_arg_offset(PredFormArityInt - CurrentArity).
> +
> +higher_order_modecheck_arg_offset = modecheck_arg_offset(1).

Is this because a higher order call is really call(HOTerm, Arg1, ...)?

> +
> +unify_method_event_cast_modecheck_arg_offset = modecheck_arg_offset(0).
>  
>  %---------------------------------------------------------------------------%
>  

That looks fine, otherwise.

Peter