[m-rev.] for review: compute imp imported modules in .int files more directly

Julien Fischer jfischer at opturion.com
Fri Aug 2 12:25:26 AEST 2019


On Thu, 1 Aug 2019, Zoltan Somogyi wrote:

> For review by anyone.

> Compute which modules to import in .int files more directly.
> 
> compiler/comp_unit_interface.m:
>     Instead of computing (a) a set of modules we should import in the interface
>     and (b) *whether* we need to import *any* modules in the interface,
>     switch to using just (a). Part (b) was flawed anyway. Besides saying
>     that items that added modules to (a) needed imported modules, it also
>     said that e.g. definitions of dummy and enum types needed imported modules,
>     which they do not.
>
>     Switch from handling imports and uses as lists of items
>     to handling them as sets of the names of imported and used modules.
>     Given the four sets
>         imported in interface
>         used in interface
>         imported in implementation
>         used in implementation
>     we use this to ensure that
>     (a) no module can appear more than once in a set, and
>     (b) no module can appear in more than one set.
>
>     Add XXXs documenting possible further improvements.
>
>     Separate the two jobs of make_imp_type_abstract.
> 
> compiler/notes/interface_files.html:
>     Describe what import_module and use_module declarations
>     we put into .int files.
> 
> diff --git a/compiler/comp_unit_interface.m b/compiler/comp_unit_interface.m
> index 679c1dcaf..dfafe1e7e 100644
> --- a/compiler/comp_unit_interface.m
> +++ b/compiler/comp_unit_interface.m
> 
> ...
> 
> @@ -1911,7 +1927,68 @@ make_imp_type_abstract(BothTypesMap, !ImpItemTypeDefnInfos) :-
>          % that records the presence of foreign type definitions for the type,
>          % and lists, for each foreign language with a definition, the
>          % assertions from that definition, but no more.
> -        true
> +    ).
> +
> +:- pred item_type_defn_info_is_abstract(item_type_defn_info::in) is semidet.
> +
> +item_type_defn_info_is_abstract(ItemTypeDefn) :-
> +    ItemTypeDefn ^ td_ctor_defn = parse_tree_abstract_type(_).
> +
> +:- pred make_imp_type_abstract(type_defn_map::in,
> +    item_type_defn_info::in, item_type_defn_info::out) is det.
> +
> +make_imp_type_abstract(BothTypesMap, !ImpItemTypeDefnInfo) :-
> +    % XXX TYPE_REPN We should record the aspects of the type definition
> +    % that are relevant to type representation (such as "is dummy",
> +    % "fits in n bits", "is equivalent to ...") in a type_repn item,
> +    % and then make the type definition abstract.
> +    !.ImpItemTypeDefnInfo = item_type_defn_info(_, _, TypeDefn0, _, _, _),
> +    (
> +        TypeDefn0 = parse_tree_du_type(DetailsDu0),
> +        DetailsDu0 = type_details_du(OoMCtors, MaybeEqCmp,
> +            MaybeDirectArgCtors),
> +        ( if
> +            constructor_list_represents_dummy_argument_type(BothTypesMap,
> +                OoMCtors, MaybeEqCmp, MaybeDirectArgCtors)
> +        then
> +            % Leave dummy types alone.
> +            % ZZZ Do NOT set !:ImpNeedImports.

Is that something you intended to address in this change, or a note
for later?

The change itself looks fine.

Julien.


More information about the reviews mailing list