[m-dev.] warning suppression pragmas

Peter Wang novalazy at gmail.com
Mon May 27 17:38:33 AEST 2013

On Mon, 27 May 2013 15:11:33 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
> Hi all,
> The following concerns the first of the changes listed in this diff
> of Zoltan's:
>      <http://lists.mercurylang.org/pipermail/reviews/2011-April/015128.html>
> along with my (unaddressed) review comments concerning it:
>      <http://lists.mercurylang.org/pipermail/reviews/2011-April/015129.html>
> Zoltan's diff introduced the pragma `no_determinism_warning' that can be used
> to suppress the warning that the compiler emits if a predicate's determinism
> declaration is too lax.  The original change was committed but never
> documented.
> In my review comments, I suggest generalising this mechanism so that other
> per-predicate warnings can be suppressed,
>      :- pragma suppress_warnings(<pred>/<arity>, [<warnings>])
> where <warnings> is one of: `lax_determinism' or `inferred_erroneous'.
> There are a few others that would be useful to disable in some circumstances
> as well, for example `unknown_format_calls'.

`pragma no_warn' would match command-line options and `pragma no_inline'.

> A modification of this proposal is to add another pragma that suppresses
> module level warnings.
>      :- pragma suppress_module_warnings([<module warnings>]).

Module-level warnings can already be handled by Mercury.options.

> Under this proposal the original, suppress_warnings/2 pragma would become:
>      :- pragma suppress_pred_warnings(<pred>/<arity>, [<pred warnings>])
> I am looking for feedback about whether either of my proposed generalisations
> should be implemented.  (Or indeed any other feedback regarding the original
> diff.)

I prefer we added as few such things as possible.  I haven't really
needed either your suggestions, I think.

Sometimes I would like to suppress the warnings about dead procedures
related to a mutable, when I used some but not all of the procedures
that it generated (don't have an example at hand).  But maybe the dead
procs pass should just be smarter.


More information about the developers mailing list