This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix up one mishandled plural in diagnostics in gimple-ssa-sprintf.c
- From: Martin Sebor <msebor at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, gcc-patches at gcc dot gnu dot org, David Malcolm <dmalcolm at redhat dot com>
- Date: Tue, 19 Dec 2017 11:19:44 -0700
- Subject: Re: [PATCH] Fix up one mishandled plural in diagnostics in gimple-ssa-sprintf.c
- Authentication-results: sourceware.org; auth=none
- References: <20171219172049.GT2353@tucnak> <72df07f9-9634-4a05-d2dc-e8f0fdd40bd0@gmail.com> <20171219175815.GV2353@tucnak>
On 12/19/2017 10:58 AM, Jakub Jelinek wrote:
On Tue, Dec 19, 2017 at 10:49:07AM -0700, Martin Sebor wrote:
Can the math be moved into inform_n (and warning_n) itself?
No. I'm against having dozens of inform_n and warning_n etc.
The question/suggestion is to change the existing inform_n and
warning_n functions to do the math instead of having each caller
do it. (I.e., not add any more overloads.)
overloads, it is already bad enough we have so many diagnostics
entry points now that putting breakpoints on them is so hard.
Those functions just have int, and we can have
perhaps some other function (plural_count or some better name)
that is inline and overloaded on the various types and can be used
if the count isn't int.
If the change I suggested above doesn't work for some reason
then let's consider introducing such a helper function.
As for gimple-ssa-sprintf.c, there are several other cases that
want a plural form, but I haven't changed them because
format_warning_at_substring doesn't have _n suffixed variant.
Yes, I think I mentioned that. It involves adding even more
"overloads." I'm not a fan of a proliferation of APIs with
only subtle differences either. They are too easy to misuse.
I'd prefer fewer "smart" APIs that git it right on their own.
It's probably too late to add something like that for GCC 8
but I'm hoping we can come up with an idea and implement it
in GCC 9 to avoid these pitfalls while (hopefully) also
making it easier to write messages involving more than one
plural form.
Martin