On Tue, Jul 31, 2018 at 02:56:29PM +0200, Richard Biener wrote: > On Fri, Jul 27, 2018 at 11:48 PM David Malcolm <dmalc...@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