This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Not quoted option names in errors and warnings
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