[m-rev.] for review: centralize adding items in make_hlds_passes.m.

[Zoltan Somogyi]

2021-05-24 21:49 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
> That looks fine.

Thank you.

There is an issue with mutables that I wanted to fix for while now,
and this diff was a necessary step. The issue is that code that
implements mutables is split between two modules:
add_mutable_aux_preds.m in the make_hlds package, and
prog_mutable.m in the parse_tree package.  The former
is used when we construct the HLDS, the latter when we
construct a parse_tree_int0 from a parse_tree_src.
(The .int0 file has to to contain the declarations of some of
the aux predicates that implement a mutable, so that a
submodule can call them.)

The right thing to do would be to merge these two modules,
but it was tricky to do, because

- the code in comp_unit_interface.m, which calls the code
  in prog_mutable.m, cannot import any HLDS modules, while

- the code in add_mutable_aux_preds.m built the HLDS
  and thus had to import HLDS modules.

The diff I just committed removed all updates to the HLDS
inside add_mutable_aux_preds.m, but it still leaves reads from
the HLDS. Many of these are trivial accesses to the module name
and to the globals structure, and could be trivially recoded to
avoid references to the HLDS, but there is one task for which
you *need* a data structure that is not present in the parse tree:
the type table. When generating target language code for
implementing a mutable, we need to know what string in
the target language represents the type of the mutable,
and this info can be found only in the type table if that type
is a foreign type. To eliminate this dependence on the HLDS
in the code that constructs the definitions of aux preds,
I propose to pass as an argument to that code a maybe
wrapped around a higher order value that would do
the require lookup in the type table. The code in
comp_unit_interface.m could pass this as "no",
since it does not need to construct the definition
of the mutable's global var.

There are also references to the pred_c_names type,
newly renamed to pred_target_names, which is now defined
in hlds_module.m but could be moved to prog_item.m or
prog_data.m.

I propose to move to prog_mutable.m

- the predicate mutable_public_aux_pred_decls now in
  comp_unit_interface.m, and

- everything in add_mutable_aux_preds.m that constructs
  the declarations and definitions of predicates and the foreign
  code fragments that support them. This means everything
  from about line 540 to about line 1650 (after this recent diff).

The code of check_mutable would remain in add_mutable_aux_preds.m,
because the construction of the error messages needs the HLDS.
This means that its caller would have to stay in the module too.
That call would be moved to the implement_mutables_loop predicate,
which would also stay, along with its own ancestor.

The interface of prog_mutable.m would go from about ten
exported functions and predicates to just two, one each
for comp_unit_interface.m and the rump add_mutable_aux_preds.m.
And its implementation section could be reordered to finally put
the declaration of each aux pred next to its implementation,
instead of being in different modules.

I also propose to move the huge initial comment that describes
the target code we want to generate for various kinds of mutables
to a file in compiler/notes, with a mention at the top of prog_mutable.m.
Having that info available is nice, but having to jump over it
every time you start editing a source file gets old very fast.

Any opinions, or objections?

Zoltan.