[m-dev.] new option for library modules

[Zoltan Somogyi]

On Tue, 21 Dec 2021 11:24:26 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> Would the check only catch exact matches, or would it also check for
> submodules whose unqualfied or partially qualified name matches a
> library module?  I have had problems with in several projects containing
> modules named like:
> 
>      cadmium
>      cadmium.parser

I was originally thinking about only exact matches, but you are right,
we need to handle other kinds of "name confusion" as well.
 
> (Arguably, that should be alright but you can end up with unresolvable
> ambiguities as Mercury doesn't have a way to explicitly specify the top
> of the module hierarchy.)

Agreed. I therefore propose that we should generate a warning
if the partial_sym_name_is_part_of_full test in mdbcomp/sym_name.m
succeeds when passed the name of a Mercury stdlib module as the
PartialSymName and the module name we are deciding whether
to warn about as the CompleteSymName. If this test succeeds,
then any reference to the stdlib module's name is ambiguous,
even if fully qualified, since it could also be a reference to the user's module.

I also propose to use simpler wording in the error message
when the two module names are identical, and more extensive wording
(explaining the above) when they are not identical but the above test still succeeds.

> > The second part would ensure that the list is not missing any entries.
> >
> > The list could have two halves, the publicly documented modules
> > vs the rest, so that the warning in the first case could be a bit more
> > expansive in the second case.
> >
> > One minor issue is that this would make adding a new module
> > to the library a two-step process: either add the name to the list,
> > then add the module,
> 
> The first suggestion would making working on changes that add new
> standard library modules really annoying.  Particularly, since some
> standard library module names are not finalised until *after* they
> are reviewed.
> 
> > or add the module while disabling this option for it, then later undo
> > the disabling.
> 
> By adding an appropriate entry to the Mercury.options file?

That was my initial intention, yes. But I agree with Peter, this
extra step, though not onerous, is still annoying. I have come up
with another way to reach the objective it was designed to reach.

The option I proposed earlier, which Peter proposed be called
--warn-redefine-stdlib-module, would now operate only when enabled,
causing the above check to be made. library/LIB_FLAGS would
contain --no-warn-redefine-stdlib-module, turning this check,
and therefore the warning, off.

Since the compiler wouldn't do anything with --no-warn-...,
it wouldn't help us catch situations in which we add a module
to the standard library without adding its name to the list
of standard library module names. To fix this, I propose adding
*yet another* new option, called maybe --output-stdlib-modules,
that would have one task, which would be to set the op_mode
to a new op_mode_query, called maybe opmq_output_stdlib_modules.
We could then modify tools/bootcheck to compare the list of module
names in the library directory against the output of the compiler
with this option, reporting an error in the case of a mismatch.

Opinions about these changes?

And given that this updated proposal can generate warnings
for nonexact module name matches, is the "redefine" part of
--warn-redefine-stdlib-module still descriptive? Should the name
be more like --warn-confusable-with-stdlib-module-name,
or just --warn-confusable-with-stdlib?

Zoltan.