[m-dev.] IL grade broken

[Peter Ross]

I think stayls recent change to make definitions of abstract types
available when generating code for importing modules, exposed a bug in
the IL backend.

What is happening is that in mer_std.il for example we are generating
the following code

.method private static default
        bool
        'special___Unify___array_1_0'(
                object[] 'TypeInfo_for_T_3',
                class ['mscorlib']'System'.'Array' 'HeadVar__1_1',
                class ['mscorlib']'System'.'Array' 'HeadVar__2_2'
        )
{
.maxstack 3

        .line 7 'array.int2'

        .line 7 'array.int2'
        {       // #1
        ldarg.0
        ldarg.1
        ldarg.2
        call    bool
                ['mer_std__csharp_code']'mer_std__csharp_code'.'mercury_code'::'special___Unify___array_1_0'(
                        object[],
                        class ['mscorlib']'System'.'Array',
                        class ['mscorlib']'System'.'Array'
                )
        }       // #1
        ret
}

ilasm barfs on this because we don't have an assembly reference to
mer_std__csharp_code earlier, however I don't think we should be
generating this code at all because there is mer_std__csharp_code which
contains special___Unify___array_1_0.

which comes from the following HLDS

:- pred mer_std.'__Unify__'((private_builtin.type_info(T_1)), (array.array(T_1)), (array.array(T_1))).
% pred id: 1587, category: predicate, status: external (and local)
% goal_type: none
% type_info varmap:
% T_1 (number 1) -> type_info(TypeInfo_for_T_3)  (number 3)
% typeclass_info varmap:
% head_type_params:
% T_1, T_1
% variable types map:
% HeadVar__1_1 (number 1): (array.array(T_1))
% HeadVar__2_2 (number 2): (array.array(T_1))
% TypeInfo_for_T_3 (number 3): (private_builtin.type_info(T_1))
	% pred id 1587
	% mode number 0 of unification predicate for type constructor array.array (semidet):
% Arg size properties: not_set
% Termination properties: not_set
% variable types map:
% HeadVar__1_1 (number 1): (array.array(T_1))
% HeadVar__2_2 (number 2): (array.array(T_1))
% TypeInfo_for_T_3 (number 3): (private_builtin.type_info(T_1))
% type_info varmap:
% T_1 (number 1) -> type_info(TypeInfo_for_T_3)  (number 3)
% typeclass_info varmap:
% address is not taken
:- mode '__Unify__'((builtin.in), (ground -> ground), (ground -> ground)) is semidet.
mer_std.'__Unify__'(TypeInfo_for_T_3, HeadVar__1_1, HeadVar__2_2) :-
	% determinism: erroneous
	true.
	% new insts: unreachable

The key point to not is the status: external (and local), which is
causing the code to be generated in this manner.  What I am having
trouble with is working out what the best fix for this is, any
suggestions welcome.

The condition which causes this is bug is for types whose definition is a
foreign_type which is imported into another module, we have a similar
problem for time__time_t_rep.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------