[m-rev.] for review: allow execution of incomplete programs

[Fergus Henderson]

On 21-Feb-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 21-Feb-2003, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > 
> > Use hlds_goal__make_string_const_construction.
> > 
> > Use goal_util__generate_simple_call.
> 
> Good idea, thanks!

Actually, it turned out that there was a problem with using
hlds_goal__make_string_const_construction.  This caused an
abort in polymorphism.m, because make_string_const_construction
returns a unification which has already been mode-analyzed
as a `construction', whereas polymorphism was expecting that
its input had not been mode analyzed and thus had all unifications
marked as `complicated_unify', which is how we record them until
they have been mode-analyzed. 

The reasons that polymorphism.m was making that assumption was because it
needs somewhere to store the type_info_vars for the unification, in case
the unification should (after mode analysis) turn out tot be a complicated
unification, because in that case the type_info_vars will be needed.
But if the unification has already been determined to not be a
complicated unification, we don't need to save the type_info_vars for
it.  So this assumption is not necessary.

Hence the following patch.

----------

Estimated hours taken: 0.5
Branches: main

Fix a bug where the stub code generated with `--allow-stubs'
was violating an invariant that polymorphism pass was relying on.

compiler/polymorphism.m:
	Allow unifications whose kind (construction, deconstruction,
	simple_test, etc.) has already been determined.

Workspace: /home/ceres/fjh/mercury
Index: compiler/polymorphism.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/polymorphism.m,v
retrieving revision 1.230
diff -u -d -r1.230 polymorphism.m
--- compiler/polymorphism.m	27 Jan 2003 09:20:50 -0000	1.230
+++ compiler/polymorphism.m	21 Feb 2003 03:29:23 -0000
@@ -1300,7 +1300,11 @@
 	( Unification0 = complicated_unify(Modes, CanFail, _) ->
 		Unification = complicated_unify(Modes, CanFail, TypeInfoVars)
 	;
-		error("polymorphism__unification_typeinfos")
+		% This can happen if an earlier stage of compilation
+		% has already determined that this unification is particular
+		% kind of unification.  In that case, the type_info vars
+		% won't be needed.
+		Unification = Unification0
 	).
 
 :- pred polymorphism__process_unify_functor(prog_var, cons_id, list(prog_var),


-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------