[m-dev.] for review: --stack-trace-higher-order

[Zoltan Somogyi]

>> compiler/llds_out.m:
>>        Reorganize the way the way the initialization functions are generated,
>>        by putting c_modules falling into different categories into different
>>        bunches. c_module falling into the first category always have their
>>        initialization code included, while those in the second category
>>        have it included only if the old flag MR_MAY_NEED_INITIALIZATION
>>        is set.
> 
> I think this won't have the intended effect, because the if
> MR_MAY_NEED_INITIALIZATION is not set, then the initialization
> functions won't be called, even if they are included.

Which initialization functions won't be called from where?

With --stack-trace-higher-order, the new compiler generates the following code
at the end of library/list.c:

	static void mercury__list_always_bunch_0(void)
	{
		list_module55();
		<deletia>
		list_module92();
	}

	#ifdef MR_MAY_NEED_INITIALIZATION

	static void mercury__list_maybe_bunch_0(void)
	{
		list_module0();
		<deletia>
		list_module39();
	}

	static void mercury__list_maybe_bunch_1(void)
	{
		list_module40();
		<deletia>
		list_module95();
	}

	#endif

	<deletia>
	void mercury__list__init(void)
	{
		static bool done = FALSE;
		if (!done) {
			done = TRUE;
			mercury__list_always_bunch_0();

	#ifdef MR_MAY_NEED_INITIALIZATION
			mercury__list_maybe_bunch_0();
			mercury__list_maybe_bunch_1();
	#endif

			MR_INIT_BASE_TYPE_INFO(
			mercury_data_list__base_type_info_list_1,
				list__list_1_0);
		}
	}

As you can see, any call to mercury__list__init *will* cause the initialization
functions of the modules containing the implementations of higher order preds
to be called.

If you are worried about mercury__list__init itself not being called,
you are right, by default it won't be. However, overriding that default
is what the options to c2init are for.

Zoltan.