[m-rev.] Diff: Bug fix for Java grade RTTI definitions

[James Goddard]

Estimated hours taken: 6
Branches: main

Bug fix for Java grade RTTI definitions.

compiler/rtti_to_mlds.m:
	Re-ordered the output of definitions so that subdefinitions always
	appear before the definition which uses them.
	This is neccessary because in Java, static initializers are performed
	at runtime in textual order, and if a definition relies on another
	static variable for its constructor but said variable has not been
	initialized, then it is treated as `null' by the JVM with no warning.
	This change should not effect the other back-ends.
	Also added an XXX comment about this invariant.

compiler/mlds_to_java.m:
compiler/mlds.m:
	Document the invariant above.



Index: rtti_to_mlds.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/rtti_to_mlds.m,v
retrieving revision 1.48
diff -u -d -r1.48 rtti_to_mlds.m
--- rtti_to_mlds.m	20 Feb 2004 02:18:47 -0000	1.48
+++ rtti_to_mlds.m	26 Feb 2004 06:25:28 -0000
@@ -12,6 +12,21 @@
 % The RTTI data structures are used for static data that is used
 % for handling RTTI, polymorphism, and typeclasses.
 %
+% XXX There are problems with these definitions for the Java back-end.
+% Under the current system, the definitions are output as static variables
+% with static initializers, ordered so that subdefinitions always appear before
+% the definition which uses them.  This is neccessary because in Java, static
+% initializers are performed at runtime in textual order, and if a definition
+% relies on another static variable for its constructor but said variable has
+% not been initialized, then it is treated as `null' by the JVM with no
+% warning.
+% The problem with this approach is that it won't work for cyclic definitions.
+% eg:
+%	:- type foo ---> f(bar) ; g.
+%	:- type bar ---> f2(foo) ; g2
+% At some point this should be changed so that initialization is performed by 2
+% phases: first allocate all of the objects, then fill in the fields.
+%
 %-----------------------------------------------------------------------------%
 
 :- module ml_backend__rtti_to_mlds.
@@ -80,7 +95,7 @@
 			Initializer, ExtraDefns),
 		rtti_entity_name_and_init_to_defn(Name, RttiId, Initializer,
 			MLDS_Defn),
-		MLDS_Defns = [MLDS_Defn | ExtraDefns]
+		MLDS_Defns = list__append(ExtraDefns, [MLDS_Defn])
 	).
 
 :- pred rtti_name_and_init_to_defn(rtti_type_ctor::in, ctor_rtti_name::in,
@@ -501,7 +516,8 @@
 			enum_value_ordered_table),
 		FunctorInit = gen_init_rtti_name(ModuleName, RttiTypeCtor,
 			enum_name_ordered_table),
-		Defns = [ByValueDefn, ByNameDefn | EnumFunctorDescs]
+		Defns = list__append(
+			EnumFunctorDescs, [ByValueDefn, ByNameDefn])
 	;
 		TypeCtorDetails = du(_, DuFunctors, DuByPtag, DuByName),
 		DuFunctorDefnLists = list__map(
@@ -516,8 +532,8 @@
 			du_ptag_ordered_table),
 		FunctorInit = gen_init_rtti_name(ModuleName, RttiTypeCtor,
 			du_name_ordered_table),
-		Defns = [ByNameDefn |
-			list__append(ByPtagDefns, DuFunctorDefns)]
+		Defns = list__append(
+			DuFunctorDefns, [ByNameDefn | ByPtagDefns])
 	;
 		TypeCtorDetails = reserved(_, MaybeResFunctors, ResFunctors,
 			DuByPtag, MaybeResByName),
@@ -599,7 +615,7 @@
 		gen_init_maybe(ml_string_type, gen_init_string, MaybeArgName)
 	]),
 	rtti_id_and_init_to_defn(RttiId, Init, MLDS_Defn),
-	MLDS_Defns = [MLDS_Defn | SubDefns].
+	MLDS_Defns = list__append(SubDefns, [MLDS_Defn]).
 
 :- func gen_du_functor_desc(module_info, rtti_type_ctor, du_functor)
 	= list(mlds__defn).
@@ -686,7 +702,7 @@
 		ExistInfoInit
 	]),
 	rtti_id_and_init_to_defn(RttiId, Init, MLDS_Defn),
-	MLDS_Defns = [MLDS_Defn | SubDefns].
+	MLDS_Defns = list__append(SubDefns, [MLDS_Defn]).
 
 :- func gen_res_addr_functor_desc(module_info, rtti_type_ctor,
 	reserved_functor) = mlds__defn.
@@ -844,7 +860,7 @@
 	gen_pseudo_type_info_array(ModuleInfo, TypeRttiDatas, Init, SubDefns),
 	RttiName = field_types(Ordinal),
 	rtti_name_and_init_to_defn(RttiTypeCtor, RttiName, Init, MLDS_Defn),
-	MLDS_Defns = [MLDS_Defn | SubDefns].
+	MLDS_Defns = list__append(SubDefns, [MLDS_Defn]).
 
 %-----------------------------------------------------------------------------%
 
@@ -911,7 +927,7 @@
 	RttiName = du_ptag_ordered_table,
  	Init = init_array(list__append(PtagInitPrefix, PtagInits)),
 	rtti_name_and_init_to_defn(RttiTypeCtor, RttiName, Init, MLDS_Defn),
-	MLDS_Defns = [MLDS_Defn | SubDefns].
+	MLDS_Defns = list__append(SubDefns, [MLDS_Defn]).
 
 :- func gen_du_ptag_ordered_table_body(module_name, rtti_type_ctor,
 	assoc_list(int, sectag_table), int) = list(mlds__initializer).
@@ -998,7 +1014,7 @@
 			du_ptag_ordered_table)
 	]),
 	rtti_id_and_init_to_defn(RttiId, Init, MLDS_Defn),
-	MLDS_Defns = [MLDS_Defn | SubDefns].
+	MLDS_Defns = list__append(SubDefns, [MLDS_Defn]).
 
 :- func gen_res_addr_functor_table(module_name, rtti_type_ctor,
 	list(reserved_functor)) = mlds__defn.
Index: mlds.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/mlds.m,v
retrieving revision 1.108
diff -u -d -r1.108 mlds.m
--- mlds.m	3 Feb 2004 05:40:00 -0000	1.108
+++ mlds.m	26 Feb 2004 03:52:34 -0000
@@ -156,6 +156,21 @@
 % the constructor name is the same as the type name.
 %
 % XXX Also need to think about equivalence types and no_tag types.
+%
+% XXX There are problems with the RTTI definitions for the Java back-end.
+% Under the current system, the definitions are output as static variables
+% with static initializers, ordered so that subdefinitions always appear before
+% the definition which uses them.  This is neccessary because in Java, static
+% initializers are performed at runtime in textual order, and if a definition
+% relies on another static variable for its constructor but said variable has
+% not been initialized, then it is treated as `null' by the JVM with no
+% warning.
+% The problem with this approach is that it won't work for cyclic definitions.
+% eg:
+%       :- type foo ---> f(bar) ; g.
+%       :- type bar ---> f2(foo) ; g2
+% At some point this should be changed so that initialization is performed by 2
+% phases: first allocate all of the objects, then fill in the fields.
 
 % 8.  Insts and modes
 %
Index: mlds_to_java.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/mlds_to_java.m,v
retrieving revision 1.53
diff -u -d -r1.53 mlds_to_java.m
--- mlds_to_java.m	20 Feb 2004 07:14:51 -0000	1.53
+++ mlds_to_java.m	26 Feb 2004 03:55:49 -0000
@@ -37,6 +37,24 @@
 %		able to coerce between different types that have the same
 %		initial fields (e.g. FA_TypeInfo_Struct and TypeInfo_Struct),
 %		and that doesn't work in Java.
+%
+%		XXX There are problems with the RTTI definitions for the Java
+%		back-end.  Under the current system, the definitions are output
+%		as static variables with static initializers, ordered so that
+%		subdefinitions always appear before the definition which uses
+%		them.  This is neccessary because in Java, static initializers
+%		are performed at runtime in textual order, and if a definition
+%		relies on another static variable for its constructor but said
+%		variable has not been initialized, then it is treated as `null'
+%		by the JVM with no warning.
+%		The problem with this approach is that it won't work for cyclic
+%		definitions.  eg:
+%			:- type foo ---> f(bar) ; g.
+%			:- type bar ---> f2(foo) ; g2
+%		At some point this should be changed so that initialization is
+%		performed by 2 phases: first allocate all of the objects, then
+%		fill in the fields.
+%
 %	generate names of classes etc. correctly (mostly same as IL backend)
 %	support foreign_import_module for Java
 %	handle foreign code written in C 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------