[m-rev.] for review: delete the {int, imp}_deps field from module_and_imports

Julien Fischer jfischer at opturion.com
Wed Aug 11 15:04:05 AEST 2021


Hi Zoltan,

On Tue, 10 Aug 2021, Zoltan Somogyi wrote:

> Delete module_and_imports' {int,imp}_deps fields.
> 
> compiler/module_imports.m:
>     Delete module_and_imports' {int,imp}_deps fields, as their contents
>     are computable from the field containing the parse_tree_module_src.
>
>     Add a utility predicate that returns the int and imp dependencies
>     separately. Clients for whom the int/imp distinction is not relevant
>     can get the union of those sets more simply by just taking the
>     key set of the parse_tree_module_src's import_and_or_use_map.
>
>     Delete now unneeded arguments.
>
>     Make some minor rearrangements to minimize the remaining differences
>     between the two methods of initializing module_and_imports structures,
>     init_module_and_imports and make_module_and_imports.
> 
> compiler/grab_modules.m:
> compiler/make.module_dep_file.m:
> compiler/mercury_compile_main.m:
> compiler/write_deps_file.m:
>     Conform to the change above.

...

> diff --git a/compiler/mercury_compile_main.m b/compiler/mercury_compile_main.m
> index a5fa8eedc..4f63d31b7 100644
> --- a/compiler/mercury_compile_main.m
> +++ b/compiler/mercury_compile_main.m
> @@ -2193,9 +2193,14 @@ maybe_grab_plain_and_trans_opt_files(Globals, OpModeAugment, Verbose,
>              % ancestor modules.
>              module_and_imports_get_module_name(ModuleAndImports0, ModuleName),
>              Ancestors = get_ancestors_set(ModuleName),
> -            module_and_imports_get_int_deps_set(ModuleAndImports0, IntDeps),
> -            module_and_imports_get_imp_deps_set(ModuleAndImports0, ImpDeps),
> -            TransOptFiles = set.union_list([Ancestors, IntDeps, ImpDeps]),
> +            module_and_imports_get_parse_tree_module_src(ModuleAndImports0,
> +                ParseTreeModuleSrc),
> +            Deps0 = map.keys_as_set(ParseTreeModuleSrc ^ ptms_import_use_map),
> +            % Some builtin modules can implicitly depend on themselves.

It would be worth giving an example of such an implicit self-dependency here.

> +            % For those, we don't want to read in their .trans_opt file,
> +            % since we have already in their .m file.

      ... since we already have their .m file.


The rest looks fine.

Julien.


More information about the reviews mailing list