[m-rev.] for review: simplify decisions about FIMs in .int files

Julien Fischer jfischer at opturion.com
Wed Jul 31 16:35:55 AEST 2019


On Tue, 30 Jul 2019, Zoltan Somogyi wrote:

> This simplifies the algorithms we use to decide which foreign_import_module
> items we put into .int files. This algorithm happens to generate exactly the same
> .int files as the old one on the compiler, but there may be differences for other
> code bases. However, even if there are, these differences are likely to consist of
> the new algorithm deleting redundant foreign_import_modules that the old one
> generated.

> Simplify the code putting foreign_import_modules into .int files.
> 
> compiler/comp_unit_interface.m:
>     Decide what foreign_import_modules (FIMs) items we need to put
>     into .int files when we decide to put into the .int file
>     the item (e.g. the definition of a foreign type) that *needs* the FIM.
>     This means gathering information about which FIMs are needed
>     during the pass that processes all the items in the .m file,
>     instead of separate later passes over all items.
>
>     Switch from handling these FIMs as lists to handling them as sets,
>     with respect to both FIMs that are explicit in the .m file, and those
>     that are implicitly needed. This eliminates the possibility of
>     including the same FIM in the .int file twice.
>
>     Put both explicit and implicit FIMs from each section of the .m file
>     into the corresponding section of the .int file.
>
>     Do not put into the implementation section of the .int file
>     a FIM item that we put into its interface section.
>
>     Clarify in variable names which section we are processing.
>
>     Disambiguate the func vs pred versions of some calls to init.

That looks fine.

Julien.


More information about the reviews mailing list