[m-rev.] for review: unexported types/insts/modes in interfaces
Julien Fischer
jfischer at opturion.com
Wed Nov 11 14:00:06 AEDT 2015
Hi Zoltan,
On Wed, 11 Nov 2015, Zoltan Somogyi wrote:
> This diff fixes Mantis bug 17, but as the diff shows, the library,
> browser and compiler all had instances of this bug, and thus
> it is very likely that other code does as well. Although referring
> to locally-defined but unexported types, insts and modes was
> documented to be non-allowed, the bug allowed them in practice,
> so fixing this bug effectively makes till-now-accepted programs
> no longer accepted by the compiler.
...
> Require that types/insts/modes in interfaces be defined in the interface.
>
> compiler/module_qual.m:
> The interface of a module A contains items (e.g. predicate declarations)
> that refer to entities such as types, insts, modes etc. They may refer
> to those entities if they are defined either in the interface of module A,
> or if they are imported from another module, module B, which is imported
> into module A in the interface of module A.
Or they may be implicitly imported from an ancestor module of A. A related
question: is the following supposed to be allowed?
:- module foo.
:- interface.
:- module bar.
:- interface.
:- type bar_t ---> bar_t(foo_t).
:- end_module bar.
:- implementation.
:- type foo_t ---> foo_t.
:- end_module foo.
The current submodule visibility rules say yes, but letting foo_t/0 escape from
the implementation section of the module foo seems a bit odd. (Granted, there's
not much any module that imports foo.bar will be able to do with it.)
> The old algorithm that attempted to enforce this requirement had a basic
> design fault: it based the decision as to whether the use of an entity
> in the interface was legal solely on the name of the module that defined
> that entity. This correctly implements the second half of the test
> above, but it does not even attempt to implement the first. It therefore
> allowed exported items to refer to nonexported entities.
>
> This diff changes the whole design approach to the test. Instead of
> keeping a list of modules *all* of whose entities may be used in the
> interface of the current module, record for *every* entity whether
> it may be used in the interface. Set the permissions differently
> in the interface and implementation sections of the current module.
>
> Improve the formatting of the ambiguity error message.
>
> NEWS:
> Announce the stricter enforcement of the documented language rules.
I think we should add a new section to the top of the NEWS file and shift all
of the changes that are potentially going to "break" existing programs (i.e.
programs that compiled with Mercury 14.01.X) to there. For the next release,
there are a number of such changes.
The diff looks fine.
Julien.
More information about the reviews
mailing list