On Tue, 2019-04-09 at 09:21 +0200, Jakub Jelinek wrote: > Hi! > > Several further spots with trailing whitespace, only > bootstrapped/regtested > on x86_64-linux and i686-linux (so the ipa-devirt.c change is > covered), > the rest is just by eyeballing gcc.pot. > > Ok for trunk? > > I wonder where and how we could check for this kind of errors, > unfortunately > the strings are extracted by xgettext which we can't easily patch for > our > purposes (say to emit warnings about > "word" > "another word" > or > "word " > " another word" > or for this trailing whitespace (this one could be done even on > gcc.pot itself > by looking for ' "\nmsgstr', but unfortunately we have various cases > where > we intentionally do want those: one category is usually when it ends > with > ": ", like: > msgid "invalid 'asm': " > msgstr "" > (many cases), but there are even > "Go ahead? (y or n) " > msgstr "" > or > msgid "The following options are specific to just the language " > msgstr "" > "%s\tcompiled by GNU C version %s, " > msgstr "" > msgid "vtable for " > msgstr "" > msgid "%r%s:%d:%d:%R " > msgstr "" > etc., so it is hard to do this programmatically, unless we had some > white > list.
Thinking aloud, maybe c-format.c could check for some of these? (provided they're at a suitable callsite). We're already statically checking for valid format codes/types for strings at callsites of decls with ATTRIBUTE_GCC_DIAG; maybe that test could also check for things like trailing whitespace within the string? Wouldn't help for the LINK_SPEC things, though. Dave [...snip...]
