[m-rev.] for review: disable_warning [unknown_format_calls]

[Zoltan Somogyi]

On Wed, 7 Sep 2022 19:31:22 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> > But the other instances of disable_warning scopes for this warning
> > *could* be avoided with a pragma such as you suggest.
> 
> My intent was not avoid the disable_warnings scopes, but to check calls
> to the wrapper predicates.

I knew that, but the presence of such a pragma *should*, I think,
disable the unknown_format_call warning, *for any call constructed
using the nominated format_string/poly_types arguments*.

> I have been bitten a non-trivial number of times by calls to log_msg/5
> above containing invalid format strings. Had these been calls to, for
> example, string.format the compiler would have caught such errors.

I figured as much.

> > I would propose that intead of format_args(2, 3) (I see no need for the []s),
> > we have two separate and more descriptive arguments, like this:
> >
> > :- pragma check_format_call(pred(pd_debug_message/5),
> >  format_string(2), poly_types(3)).
> 
> I don't have any objections to that.  The reason I used a list was that,
> in princple, you can certainly write predicates with multiple format
> string and multiple list of poly_type arguments. (It's argubly, not a
> particularly useful thing to do.)

Ah. In that case, I propose that after the identification of the pred/func,
the second argument should either have the format "format_string_poly_types(N, M)",
where N & M are the argument numbers of the format string and the poly types
respectively (for the usual use case), or a list of such terms (for the use case
you just brought up). Having the format string and the poly types specified
separately would work, or at least wouldn't work well, in the latter use case.

Any objections?

Zoltan.