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

[Julien Fischer]

Hi Zoltan,

On Fri, 13 Mar 2020, Zoltan Somogyi wrote:

>
>
> 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.)

...

>
>>             - 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?

I think most of what Fergus writes above derives from the relative lack
of structure in the original Mercury frontend and those problems should
not exist in recent versions where that structure is now much more
defined.

> 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?

I don't use smart recompilation.  It does not apear to have ever been
extended to work with mmc --make** and I use the latter for everything
but Mercury itself.  It is also documented as not working properly
with --intermodule-optimization.  In short, I don't think anyone can
be relying on it for anything important.

** or if it was, it's definitely broken and there are several very
out-fo-date comments in the compiler.

Julien.