Re: [PATCH 4/5] c-family: clean up the data tables in c-format.c

[Marek Polacek <polacek@redhat.com>]

On Tue, Jul 31, 2018 at 02:56:29PM +0200, Richard Biener wrote:
> On Fri, Jul 27, 2018 at 11:48 PM David Malcolm <dmalcolm@redhat.com> wrote:
> >
> > The format_char_info tables in c-format.c for our own formats contain
> > a lot of repetition.
> >
> > This patch adds a macro to express the conversion specifiers implemented
> > within pp_format, making it clearer which are custom ones added by the
> > various diagnostic_format_decoder callbacks.
> >
> > Doing so uncovered a few mistakes in the data (based on comparison with
> > the source of the diagnostic_format_decoder callbacks, and the notes
> > below), which the patch fixes:
> >
> > - gcc_diag_char_table didn't have 'Z', but it *is* implemented by pp_format.
> >
> > - removed erroneous 'G' and 'K' entries from gcc_diag_char_table: they're
> >   implemented by default_tree_printer (and thus in "tdiag") and by the
> >   C/C++ FEs, but not in pp_format.
> >
> > - removed "v" (lower case) from gcc_tdiag_char_table and
> >   gcc_cxxdiag_char_table
> >
> > Notes:
> >
> > pretty-print.h uses this for ATTRIBUTE_GCC_PPDIAG, used by pp_printf
> > and pp_verbatim:
> >
> > whereas diagnostic-core.h uses this for ATTRIBUTE_GCC_DIAG, used by
> > the various diagnostic functions:
> >
> > /* If we haven't already defined a front-end-specific diagnostics
> >    style, use the generic one.  */
> >
> > Hence I'm assuming that __gcc_diag__ is for use for when we don't
> > know what kind of diagnostic_format_decoder we have, and we can
> > only rely on pp_format's core functionality, where __gcc_tdiag__
> > is allowed to assume default_tree_printer.
> 
> OK if nobody objects.

Looks fine to me, too.

Marek