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

Peter Wang novalazy at gmail.com
Sat Feb 23 15:08:45 AEDT 2019


On Sat, 23 Feb 2019 14:06:24 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 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.)

Prince was failing to compile for the same reason, and
also compiles fine with the new algorithm (i.e. with the
sanity checks deleted).

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

It sounds right to me.

Peter


More information about the reviews mailing list