[m-rev.] for post-commit review: replace grab_modules.m's module comment

Julien Fischer jfischer at opturion.com
Fri Oct 6 22:52:59 AEDT 2023


On Fri, 6 Oct 2023, Zoltan Somogyi wrote:

> diff --git a/compiler/grab_modules.m b/compiler/grab_modules.m
> index a4afb575f..8e035692a 100644
> --- a/compiler/grab_modules.m
> +++ b/compiler/grab_modules.m
> @@ -9,16 +9,37 @@
>  % File: grab_modules.m.
>  % Main author: fjh (original), zs (current).
>  %
> -% Given a module_and_imports structure initialized for a raw_comp_unit,
> -% this module has the task of figuring out which interface files the
> -% raw_comp_unit needs either directly or indirectly, and reading them in,
> -% adding them to the module_and_imports structure. If intermodule optimization
> -% is enabled, then calls to grab_plain_opt_and_int_for_opt_files and maybe
> -% grab_trans_opt_files will figure out what .opt and .trans_opt files
> -% the compilation unit can use, again either directly or indirectly,
> -% and add those, and the interface files they need, to the module_and_imports
> -% structure. When all this is done, the module_and_imports structure
> -% will contain an augmented version of the original compilation unit.
> +% When the compiler is processing a module, it uses the code in this module
> +% to grab files that earlier compiler invocations have automatically generated
> +% for some of the *other* modules of the program.
> +%
> +% This module does this in four circumstances, each of which requires it
> +% to perform a different set of files from a different set of modules.

s/perform/grab/

> +% 1     grab_unqual_imported_modules_make_int performs the task that is
> +%       chronologically first in the build-system lifecycle of a module,
> +%       named (say) module A. This task is to grab all the .int3 files needed
> +%       for the creation of A.int0, A.int, and A.int2. This task returns

...

> @@ -51,27 +72,22 @@
>  %---------------------------------------------------------------------------%
>
>      % grab_qual_imported_modules_augment(ProgressStream, Globals,
> -    %   SourceFileName, SourceFileModuleName, MaybeTimestamp, NestedSubModules,
> -    %   ParseTreeModuleSrc, AugCompUnit, !HaveReadModuleMaps, !IO):
> +    %   SourceFileName, SourceFileModuleName, MaybeTimestamp, MaybeTopModule,
> +    %   ParseTreeModuleSrc, Baggage, AugCompUnit, !HaveReadModuleMaps, !IO):
>      %
>      % Given ParseTreeModuleSrc, one of the modules stored in SourceFileName,
> -    % read in the private interface files (.int0) for all the parent modules,
> -    % the long interface files (.int) for all the imported modules, and the
> -    % short interface files (.in2) for all the indirectly imported modules.
> -    % Return the `module_and_imports' structure containing all the information
> -    % gathered this way, from which we will compute the augmented version
> -    % of ParseTreeModuleSrc.
> -    % XXX ITEM_LIST Move the actual computation of the AugCompUnit together
> -    % with this code, preferably in a new module, perhaps named something like
> -    % "augment_comp_unit.m".
> +    % read in
> +    %
> +    % - the private interface files (.int0) for all the parent modules,
> +    % - the long interface files (.int) for all the imported modules, and
> +    % - the qualified short interface files (.in2) for all the indirectly

s/.in2/.int2/

> +    %   imported modules.
> +    %
> +    % Return the aug_compilation_unit structure containing all the information
> +    % gathered this way.

That looks fine otherwise.

Julien.



More information about the reviews mailing list