[m-rev.] for possible objection: delete strange fallback code in deps_map.m

[Zoltan Somogyi]

On Fri, 13 Mar 2020 15:02:52 +1100, Peter Wang <novalazy at gmail.com> wrote:

> On Fri, 13 Mar 2020 14:51:41 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > The diff is trivial, I am posting this just in case someone knows
> > the reason for the existence of the code that this diff deletes,
> > and thinks it should be kept. Since I don't think that is likely,
> > and I am working on a diff that builds on this, any objections
> > will have to be post-commit. (The diff passes a bootcheck.)
> 
> Maybe this helps.

Thanks for digging that up, but I am not sure it helps, because
I am not sure what *exactly* the commit message is trying to say.

>     Ensure that the `.d' files generated by `mc --generate-depencies' are
>     the same as the ones produced by `mc -c'.

Right off, I know this cannot be right, because the compiler uses
two almost completely separate code paths to generate .d files
when invoked with --generated dependencies, and when invoked
without it. Today, the former creates the module_and_imports
structure using init_module_and_imports, while the latter does it
using make_module_and_imports. I wrote both predicates, but
I did so from regrouping existing code; this distinction goes back
to before the time I started working on the pre-HLDS passes.
(When I started working on them, and found out this bifurcation,
my jaw hit the floor.)

>     compiler/modules.m:
>             - Avoid any possible duplication in the list of .int and .int2 files.

Such duplication is possible only if two source files contain modules
with the exact same fully qualified module name, since the names of the
.int/.int2 files are derived from that. If that were ever possible,
it shouldn't be now, after the change to require mmc -f for projects
that use non-default filenames for modules.

>             - When searching for files in generate_dependencies,
>               if the `.m' file is not found, look for the `.int' file instead.
>               (Necessary to ensure that the `.d' files are identical.)

Are identical between what two situations? If the situations are
with and without --generate-dependencies, then, due to the separate
code paths, it is far from sufficient. And since I don't recall us ever having
an issue that arose from the .d files being different immediately after
--generate-dependencies and at other times, I think it is very, very likely
that both versions contain the necessary dependencies, though they may
differ in what extra, unneeded dependencies they add on top of them :-(

>             - Ensure that `.int' and `.int2' files include a `:- interface'
>               declaration.  (Necessary to make the above change work.)

The parser has been doing that check for a very long time. That could
have been a concern only during the bootstrap of a change that
added that section marker to the start of interface files.

What do people think?

BTW, I am just having a similar issue with recompilation.check.m.
Does smart recompilation work well enough now for me to expend
significant effort to preserve its current functionality, or would it be
ok for me to comment out the code I would otherwise have to update
and let whoever makes smart recompilation work eventually
update the code?

Zoltan.