Re: Slightly extended example for named warnings

[Bruce Korb <bkorb at veritas dot com>]

"Joseph S. Myers" wrote:

> We want to get rid of the _with_decl etc. diagnostic function variants

Being unaware of all the plans, I was just mimicing what I found.
Needless to say, with other mechanisms in place, one can emit
proc calls with different argument sequences.  What gets generated
is programmable.  What is in the source would never need to change.

> Of course an actual implementation would need appropriate changes to
> xgettext if messages stop being visible as C strings in the source,

Exactly.  Whatever it was xgettext was doing can be implemented
in a template and emitted directly.  xgettext could become historical.

> functionality to extract message explanations into the main manual

Trivial.  Along with names, formatting strings and (given a magic
processing flag) the source file and line number.  They can also be
sorted and/or segregated based on their groupings (not part of current
example, tho.)

> explanations - if wanted in source rather than just using info anchors in
> the manual and giving an info command that will go to the right point -
> would need careful and separate review from the rest of the patch).  I
> don't feel a need for this in the proof-of-concept examples,

No.  One has to keep a proof-of-concept within reasonable
complexity bounds.  I would need to add the grouping stuff
tho (marking a diagnostic as being "pedantic" or part of
"all" [a subset of everything], etc.).

> like to see an example of how this implementation method handles more
> complicated cases - warnings which are enabled or disabled, and may or may
> not be errors, depending on multiple flags.  For example, those in
> <http://gcc.gnu.org/ml/gcc/2003-01/msg01158.html> which illustrates what
> source could look like if the enabling/disabling is parsed from a string
> at runtime.

I would set up a bitmask that would mark every diagnostic with
its group memberships.  The mask would not be constrained to
32/64 bits, but it would be "convenient" if there were not more.
This list of groups would be extracted from attributes as described in:

  http://gcc.gnu.org/ml/gcc/2003-01/msg01154.html

e.g. from this description:
>   /*=diag mumble
>    * lev: warning
>    * fmt: "some sort of format string:  %d"
>    * group: pedantic all
>    * disabled:
>    * doc:  why you got this warning
>    *       and what you might do about it.
>   =*/
>   WARNING_MUMBLE(val);

the scheme would ensure that the "pedantic" and "all" groups had defined
bits in the bit mask and that -Wall and -Wpedantic would turn this diag-
nostic on and -Wno-pedantic would turn it off, but -Wno-pedantic -Wall
would leave it on.

Alternatively, one could define a recognized list and ignore groups
not from that list.  The mechanism is programmable.