[m-rev.] for review: fix github bug 98

Julien Fischer jfischer at opturion.com
Fri Aug 20 20:03:52 AEST 2021


Hi Zoltan,

On Fri, 20 Aug 2021, Zoltan Somogyi wrote:

> Fix nonlocal typeclass_infos in rhs_lambda_goals.
> 
> This fixes github bug #98.
> 
> compiler/polymorphism.m:
>     Compiling gh98.m used to cause a compiler crash when the compiler
>     tried to look up info about a typeclass_info variable that was needed
>     in a call inside a lambda goal, but was not created inside the lambda goal.
>     It should therefore have been listed as a nonlocal of the lambda goal,
>     but it was not, because none of the variables inside the lambda goal
>     had the typeclass constraint represented by that typeclass_info var
>     on their types. And since later invocations of quantification may
>     reduce, but may not expand, the set of nonlocals in a rhs_lambda_goal
>     (as opposed to the nonlocals set of the unification whose RHS consists
>     of that rhs_lambda_goal), this problem stuck.
>
>     Fix this underestimation of the final lambda nonlocals set by including
>     in it all typeinfo and/or typeclass_info vars in the updated lambda goal.
>     Since this may then result in an overestimation, set a flag to force
>     a requantification of the whole procedure body once its polymorphism
>     transformation has been completed.

...

> diff --git a/compiler/polymorphism.m b/compiler/polymorphism.m
> index 8eac3ecaf..fb7448779 100644
> --- a/compiler/polymorphism.m
> +++ b/compiler/polymorphism.m
> @@ -2072,33 +2076,74 @@ fixup_quantification(HeadVars, ExistQVars, Goal0, Goal, !Info) :-
>      % includes the type_info variables and typeclass_info variables for
>      % any polymorphically typed variables in the nonlocals set or in the
>      % arguments (either the lambda vars or the implicit curried argument
> -    % variables). Including typeinfos for arguments which are not in the
> -    % nonlocals set of the goal, i.e. unused arguments, is necessary only
> -    % if typeinfo_liveness is set, but we do it always, since we don't have
> -    % the options available here, and the since cost is pretty minimal.
> +    % variables). We return this set of LambdaTiTciVars. Including typeinfos
> +    % for arguments which are not in the nonlocals set of the lambda goal,
> +    % i.e. unused arguments, is necessary only if typeinfo_liveness is set,
> +    % but we do it always, since we don't have the options available here,
> +    % and the since cost is pretty minimal.
> +    %
> +    % We also need to include in the nonlocals set of the lambda expression
> +    % any type_info and/or typeclass_info variables we have added to the
> +    % goal inside the lambda. In rare cases such as tests/valid/gh98.m,
> +    % a typeclass_info that we inserted into the goal inside the lambda
> +    % is defined outside the lambda *without* being in LambdaTiTciVars.
> +    % We therefore return all type_info/typeclass_info variables that occur
> +    % in the transformed lambda goal in AllTiTciGoalVars, for our caller
> +    % to likewise include in the nonlocals set of the lambda goa

s/goa/goal./

That looks fine otherwise.

Julien.


More information about the reviews mailing list