[m-dev.] warning suppression pragmas
jfischer at opturion.com
Tue May 28 13:30:13 AEST 2013
On Mon, 27 May 2013, Peter Wang wrote:
> On Mon, 27 May 2013 15:11:33 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
>> The following concerns the first of the changes listed in this diff
>> of Zoltan's:
>> along with my (unaddressed) review comments concerning it:
>> 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
>> 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'.
I'm happy with either name. (Although, for the second proposal I prefer
the suppress_*_warnings names, `no_pred_warn' and `no_module_warn' looks
a bit ugly IMO.)
>> 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.
Yes, although I think it would make the code more self-documenting if
the warning suppressions were grouped together with the module that they
affect, e.g. the pragma would serve as documentation that the programmer
intended this module to export nothing etc.
In some cases, it would also the difference between needing a
Mercury.options file and not needing one at all.
>> 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
> 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.
That's a different thing. Mutable procedures should be marked as
introduced when they are generated, so if anything in the compiler is
complaining about them then that's likely a bug.
More information about the developers