[m-rev.] diff: delete old code generating .int/.int2 files

[Zoltan Somogyi]

On Sat, 23 Feb 2019 13:00:50 +1100, Peter Wang <novalazy at gmail.com> wrote:
> Here's a program that fails to compile with the same exception:
> https://github.com/Cadmium-Language/cadmium

That program fails the sanity check when generating interface files
for one module: lib.m. The difference is this:

--- NEW/lib.int	2019-02-23 13:24:27.000000000 +1100
+++ OLD/lib.int	2019-02-23 13:08:29.000000000 +1100
@@ -2,3 +2,6 @@
 :- interface.
 :- pred lib_dummy is det.
 :- pragma foreign_import_module("C", lib).
+:- implementation.
+:- pragma foreign_import_module("C", ac_index).
+:- pragma foreign_import_module("C", machine).

I just had a look. It seems that the old code for generating
the .int file keeps the two foreign_import_module pragmas
for C in the implementation section because that section has a
foreign type definition for C: the definition of model_key.
The Mercury compiler does not know which of those modules'
.mh files may define the C type named in that foreign type
definition, so to be conservative, it says that this foreign
type definition in C requires all foreign_import_module items
for C to accompany it.

However, while that type definition is in the .m file's
implementation section, it is not in the .int file's implementation
section. So effectively, those two foreign_import_modules
are there to provide definitions for a C type that the
.int file cannot ever refer to. Since the modules that import
lib.m should not know anything about its internals, they
should not need these two foreign_import_modules.
(That is in the absence of intermodule optimization.
In its presence, they do have such a need, but that need
should be filled by the .opt or .trans_opt file, not the
.int file.)

Given that fact,  I believe that the output of the new algorithm
is just fine, and the inclusion of those two foreign_import_module
items in the output of the old algorithm was a mistake.
This means that this difference should not prevent the version
of cadmium on github from working. (The references to the
long-deleted svmap module would have to be fixed first.)

Can anyone find a flaw in that analysis? And does anyone have
any other instances of sanity check failures?

Zoltan.