[m-rev.] for review: clarify recompilation.check.m

[Julien Fischer]

On Wed, 26 Mar 2025 at 09:55, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:

> Make the code of recompilation.check.m much clearer.
>
> compiler/recompilation.used_file.m:
>     To enable some improvements in recompilation.check.m, make a field
>     of the used_file structure include more info. Do this by replacing
>     a simple list of a module's nested submodules, which cannot
>     distinguish between a module being a nested submodule and
>     a module being the top module in its source file but having
>     *no* submodules (as neither would have nested submodules),
>     with a new type equivalent to the maybe_top_module type.
>     (Neither that type nor the concept it expresses existed
>     when this module was first written.)
>
>     Do this change in a way that narrows the gap between the type
>     that represents the contents of .used files, and the type that
>     we construct on the way to creating .used files.
>
>     Update the unparsing and parsing code for .used files accordinly.

s/accordinly/accordingly/

...

> compiler/recompilation.check.m:
>     Give several predicates, types and function symbols more
>     descriptive names.
>
>     Delete some comments that the better names have made obsolete,
>     and expand and/or update others.
>
>     Move the code used to record the result of a "should we recompile"
>     decision to its own predicate.
>
>     Move the code used to handle any nested submodules of the module
>     named on the command line next to the code that handles the top
>     module in the same source file. The old code included recursive
>     invocations of a predicate that made it much harder to see what its
>     actual job was.
>
>     Delete three fields of the reccompilation_check_info structure.

s/reccompilation/recompilation/

>     Two of those fields, the module name and a flag stating whether
>     that module is a nested submodule or not, belong next to the
>     module name itself in predicate signatures, and this diff
>     puts them there. The third field, the list of the submodules
>     nested inside the top module of a source file, is now needed
>     in only one place, and so does not need to be passed around.
>
>     Try to get the contents of the .intN files of even the top module
>     in the source file from the cache of already-read parse trees.
>     We are unlikely to succeed, but the cost of the search is negligible
>     compared to the cost of reading and parsing the file.

That looks fine otherwise.

Julien.