[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