[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