[m-rev.] for review: fix mantis bug 384
Julien Fischer
jfischer at opturion.com
Thu Apr 2 11:29:52 AEDT 2015
Hi Zoltan,
On Wed, 1 Apr 2015, Zoltan Somogyi wrote:
> For review by Julien. Sorry I didn't get it done yesterday, but
> it was a bit more involved than I originally thought it would be.
>
> Fix a bug that put $typed_insts in .opt files.
>
> compiler/mercury_to_mercury.m:
> Make the predicates that output insts take a parameter that says whether
> we are trying to print valid Mercury code (in which case we strip any
> $typed_inst wrappers around other insts), or as-informative-as-possible
> representations of insts for debugging, in which case we do NOT strip
> those wrappers. When invoked on insts that CANNOT be printed as valid
> Mercury even though valid Mercury is being requested, abort.
>
> Rationalize the argument order of the involved predicates.
>
> Move the output_lang type here from hlds_out_util.m to make the above
> possible. Change the flag that governs whether item names are qualified
> or not from a bool to a bespoke enum type. Fix a bug involving that bool.
>
> compiler/hlds_out_mode.m:
> This module also has a predicate that output insts, though it already had
> a valid mercury/debug output flag. If it is asked to print valid Mercury,
> make it strip $typed_inst wrappers and abort on insts that cannot be
> printed as valid Mercury.
>
> A better fix would be to eliminate this predicate, and other predicates
> in this module that also duplicate predicates in mercury_to_mercury.m,
> after generalizing the latter as needed, but that would take more time.
...
> compiler/mode_constraint_robdd.m:
> compiler/mode_constraints.m:
> Fix an unrelated problem that ALSO prevented a bootcheck with -O5
> --intermodule-optimization, which is that with these options, several
> predicates in both these modules accumulated enough type ambiguities
> for the type checker to throw up its hands in despair.
>
> The type checker should NOT be influenced by the additional types, data
> constructors, field names, functions and predicates added by these options
> to their respective tables, but it is. Fixing that bug is future work.
> For now, just add reduce the ambiguities to the allowable level, mostly
> by adding module qualifiers, and by converting some function calls to
> predicate calls. (Function calls introduce ambiguities, since the
> typechecker thinks they may be partially applied predicate calls.)
That looks fine.
Cheers,
Julien.
More information about the reviews
mailing list