Re: Slightly more extended example for named diagnostics

[Bruce Korb <bkorb at veritas dot com>]

"Joseph S. Myers" wrote:
> > All done.  :-)
> 
> Over-simplified,

Of course it is.  It is an abbreviated example of a proof-of-concept.
>From approximately here, someone getting paid to work on GCC
needs to take over.  I already have a day job.  I figure at least
100 hours (as much as 200, depending on who) to do a properly polished job.
My wife wouldn't like me giving away that much time.

> you haven't handled all the messages that aren't covered
> by the diagnostic machinery

True.  You'd either have to append to the real xgettext output
or, as you suggest, emit some c code that doesn't get compiled,
but gets processed by xgettext.  Does xgettext honor #line directives?
My info doc for it only gives invocation information.

> > How would you like it structured?

> Ordered in some vaguely logical conceptual way.  The arrangement of
> sections in the standard isn't bad,

To order them automatically it would have to be based on
information in the comment.  That means someone would have
to go in and insert the C standard section name/number.
It can be done, but is likely less fun than an original
conversion.

> but complicated by messages shared by
> C and C++.  Where front ends have their own manuals, messages get
> documented in those manuals.  And a properly aesthetic printed manual
> requires that the documentation is in Texinfo format.

Large chunks of my manual are generated:

  http://Autogen.SourceForge.Net/doc/autogen.html

(Large chunks are written directly, too.)
It's much harder to emit that header file than it is texinfo.

> ... and put the documentation in the manual rather than the
> source, then the source just needs to reference the manual and you can
> arrange for the node (or the anchor within the node) to be named after the
> message identifier.

The "doc" piece was to accommodate "extended" messages.  For example,
printing them at the end for the triggered diagnostics.  If it were
necessary or useful to expand beyond that in the texinfo doc, one can
trivially add to it with an auxiliary file that, maybe, had stuff like:

> ==>stumble-mumble
> @enumerate
> @item
> This is more elaboration for the stumble-mumble
> diagnostic.

get added to the generated doc at the right place.  Or, just not include
any of the source code text in the doc, either.  I think this is better
though if nothing else because you can then be completely certain that
not even one diagnostic gets left out. :-)

Cheers, Bruce