On 11/21/18 1:48 AM, Martin Sebor wrote: > On 11/20/2018 12:54 PM, Martin Liška wrote: >> On 11/20/18 4:24 PM, Martin Sebor wrote: >>> On 11/20/2018 03:10 AM, Martin Liška wrote: >>>> On 11/15/18 5:54 PM, Martin Sebor wrote: >>>>> On 11/15/2018 03:12 AM, Martin Liška wrote: >>>>>> Hi. >>>>>> >>>>>> I've done a quick grep of gcc/po/gcc.pot and I see quite a lot of >>>>>> missing quotations >>>>>> of option names (~400). Is it something we should fix? How >>>>>> important is that? >>>>> >>>>> That's quite a few... I've been fixing these as I notice them, >>>>> usually as part of related changes. The most onerous part of >>>>> the cleanup is adjusting tests, especially under the target- >>>>> specific ones. It's (obviously) not critical but I think it >>>>> would be nice to make the quoting consistent throughout over >>>>> time (if not in one go) and then put in place a -Wformat >>>>> checker to detect the missing quoting as new diagnostics are >>>>> introduced. Do you think it might be scriptable? >>>> >>>> Hi. >>>> >>>> Are you talking about a proper GCC warning that will be triggered >>>> once a warning >>>> message is missing quotations? >>>> >>>> I can definitely cook a patch in next stage1 and the testsuite fall >>>> out should >>>> be easy to come with. >>> >>> Yes, issuing a -Wformat warning for __gcc_diag__ functions is what >>> I'm thinking of. A checker that would look for substrings within >>> the format string that match the "-[Wfm][a-z][a-z_1-9]*" patterns >>> (or anything else that matches an option) and point them out if >>> they're not enclosed in a pair of %< %> (or suggest to use %qs). >>> >>> Martin >> >> Sounds good to me. Well, I can imagine doing that for GCC 9 release. >> When will you find spare cycles for the warning? In can prepare >> the warning/error messages patch. > > I don't expect to have the time to work on the warning until > sometime in stage 1 (as an enhancement I also wouldn't expect > it to be approved, but maybe you can get away with it ;-) > > Martin
That's fine, I've just noticed that to my TODO list for next stage1. One related question: Is it fine to use apostrophes in dg-error/dg-warning patterns. E.g. gcc/testsuite/g++.dg/cpp1z/decomp48.C: return s; // { dg-warning "reference to local variable 's' returned" } shouldn't that be { dg-warning "reference to local variable .s. returned" }? Martin