[m-dev.] fixing the bug reported on m-users

[Julien Fischer]

Hi Zoltan,

On Tue, 2 Nov 2021, Zoltan Somogyi wrote:

> I can think of several ways to fix the problem, one for each of the first,
> second and fourth paragraphs above.
>
> Approach 1: always report errors when generating interface files.
> If we prevent the generation of .int files containing undefined modes
> (or any undefined entity detected by module qualification), the problem
> cannot arise.
>
> Approach 2: we could module qualify items we read from .int files,
> as well as the .m file, when generating target code.
>
> Approach 3: we could change the code that propagates types into modes
> to do a search, not a lookup, in the mode table, and to generate an error
> message it the mode name is not found.
>
> Approach 1 is sort-of the simplest, but it is a significant change to how
> the compiler works. When I added the option that now governs whether
> we report errors when making interface files, I intended to make it the
> default only after finishing my current series of changes.
>
> Approach 2 can be done simply, but its performance impact is nontrivial,
> given that many modules import a long list of other modules.
>
> Approach 3 has the least performance impact, but the code needed for it
> would effectively duplicate the job of module qualification. (Though it would
> be possible for post-typecheck to use the same code to generate the
> error message as module qualification.)
>
> Any preferences as to which approach I should take?

What are the disadavantages (if any) of enabling error reporting when
generating interface before you have completed your current set of
changes?

On the basis that it will be the eventual behaviour anyway, I would
otherwise say (1).

I think we can rule out (2) for performance reasons; and (3) just seems
to be making unnecessary changes *if* (1) can be enabled now.

Julien.