Clean up pretty printers [15/n]

Instead of defining the same macro several times in different
translation units, we can just make it a function and use it where
needed.

Tested on an x86_64-suse-linux.  Applied to mainline.

-- Gaby

2013-08-25  Gabriel Dos Reis  <gdr@integrable-solutions.net>
c-family/
	* c-pretty-print.h (c_pretty_printer::translate_string): Declare.
	* c-pretty-print.c (M_): Remove.
	(c_pretty_printer::translate_string): Define.
	(pp_c_type_specifier): Use it.
	(pp_c_primary_expression): Likewise.
	(pp_c_expression): Likewise.

cp/
	* cxx-pretty-print.c (M_): Remove.
	(pp_cxx_unqualified_id): Use translate_string instead of M_.
	(pp_cxx_canonical_template_parameter): Likewise.

On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:

> Instead of defining the same macro several times in different
> translation units, we can just make it a function and use it where
> needed.

Have you made sure that po/exgettext still extracts the relevant messages 
for translation (I'm not sure how good it is at identifying C++ functions 
with arguments called gmsgid, or how good xgettext then is at identifying 
relevant C++ function calls)?  In particular, even if other cases get 
identified properly, conditional expressions such as

> @@ -379,15 +375,15 @@
>  	      switch (code)
>  		{
>  		case INTEGER_TYPE:
> -		  pp_string (pp, (TYPE_UNSIGNED (t)
> -				  ? M_("<unnamed-unsigned:")
> -				  : M_("<unnamed-signed:")));
> +		  pp->translate_string (TYPE_UNSIGNED (t)
> +                                        ? "<unnamed-unsigned:"
> +                                        : "<unnamed-signed:");

may need each case of the conditional expression to be marked for 
extraction for translation, or to be separated into two separate calls 
using "if" (we've had that issue before with conditional expressions in 
diagnostics).

"Joseph S. Myers" <joseph@codesourcery.com> writes:

| On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:
| 
| > Instead of defining the same macro several times in different
| > translation units, we can just make it a function and use it where
| > needed.
| 
| Have you made sure that po/exgettext still extracts the relevant messages 
| for translation (I'm not sure how good it is at identifying C++ functions 
| with arguments called gmsgid, or how good xgettext then is at identifying 
| relevant C++ function calls)?  In particular, even if other cases get 
| identified properly, conditional expressions such as

I trusted xgettext documentation that says that it handles C++ input
source files. 

Looking at the documentation, I notice this:

       By  default  the  language  is guessed depending on the input
       file name extension.

I don't know whether after the switch C++ xgettext is being invoked
explicitly with -C or --c++, or whether we are still relying on xgettext
to pick the language based on the file extension.  This is probably
another reason why we might want to rename files to use apppropriate
extensions.  In the meantime, we might want to explicitly specify the
language for the input source file.

po/exgettext only looks whether the parameter name ends with 'msgid'.

| 
| > @@ -379,15 +375,15 @@
| >  	      switch (code)
| >  		{
| >  		case INTEGER_TYPE:
| > -		  pp_string (pp, (TYPE_UNSIGNED (t)
| > -				  ? M_("<unnamed-unsigned:")
| > -				  : M_("<unnamed-signed:")));
| > +		  pp->translate_string (TYPE_UNSIGNED (t)
| > +                                        ? "<unnamed-unsigned:"
| > +                                        : "<unnamed-signed:");
| 
| may need each case of the conditional expression to be marked for 
| extraction for translation, or to be separated into two separate calls 
| using "if" (we've had that issue before with conditional expressions in 
| diagnostics).

Hmm, why would that be needed now, and not before?
(not that I am found of the conditional, but only by curiosity.)

-- Gaby

On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:

> I don't know whether after the switch C++ xgettext is being invoked
> explicitly with -C or --c++, or whether we are still relying on xgettext
> to pick the language based on the file extension.  This is probably
> another reason why we might want to rename files to use apppropriate
> extensions.  In the meantime, we might want to explicitly specify the
> language for the input source file.
> 
> po/exgettext only looks whether the parameter name ends with 'msgid'.

And uses --language=c, --language=c++ and --language=GCC-source depending 
on the source files and functions in question.  The issue is both whether 
the awk code properly handles C++ function declarations to identify the 
parameter, and whether whatever way it passed the identified function name 
to xgettext (if it does identify the function) results in xgettext (with 
whatever language it uses) handling the call correctly.

> | > @@ -379,15 +375,15 @@
> | >  	      switch (code)
> | >  		{
> | >  		case INTEGER_TYPE:
> | > -		  pp_string (pp, (TYPE_UNSIGNED (t)
> | > -				  ? M_("<unnamed-unsigned:")
> | > -				  : M_("<unnamed-signed:")));
> | > +		  pp->translate_string (TYPE_UNSIGNED (t)
> | > +                                        ? "<unnamed-unsigned:"
> | > +                                        : "<unnamed-signed:");
> | 
> | may need each case of the conditional expression to be marked for 
> | extraction for translation, or to be separated into two separate calls 
> | using "if" (we've had that issue before with conditional expressions in 
> | diagnostics).
> 
> Hmm, why would that be needed now, and not before?
> (not that I am found of the conditional, but only by curiosity.)

Previously, each string was inside a separate call to M_() - the strings 
themselves were the msgid parameters.  Now, the msgid parameter is not a 
single string but a more complicated expression and xgettext may not 
handle such expressions properly the way it handles having just a single 
string as parameter.

"Joseph S. Myers" <joseph@codesourcery.com> writes:

[...]

| > | > @@ -379,15 +375,15 @@
| > | >  	      switch (code)
| > | >  		{
| > | >  		case INTEGER_TYPE:
| > | > -		  pp_string (pp, (TYPE_UNSIGNED (t)
| > | > -				  ? M_("<unnamed-unsigned:")
| > | > -				  : M_("<unnamed-signed:")));
| > | > +		  pp->translate_string (TYPE_UNSIGNED (t)
| > | > +                                        ? "<unnamed-unsigned:"
| > | > +                                        : "<unnamed-signed:");
| > | 
| > | may need each case of the conditional expression to be marked for 
| > | extraction for translation, or to be separated into two separate calls 
| > | using "if" (we've had that issue before with conditional expressions in 
| > | diagnostics).
| > 
| > Hmm, why would that be needed now, and not before?
| > (not that I am found of the conditional, but only by curiosity.)
| 
| Previously, each string was inside a separate call to M_() - the strings 
| themselves were the msgid parameters.  Now, the msgid parameter is not a 
| single string but a more complicated expression and xgettext may not 
| handle such expressions properly the way it handles having just a single 
| string as parameter.

OK, thanks the explanation.

Do you think the same issue arise with diagnostic_set_info,
diagnostic_append_note?

-- Gaby

On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:

> | Previously, each string was inside a separate call to M_() - the strings 
> | themselves were the msgid parameters.  Now, the msgid parameter is not a 
> | single string but a more complicated expression and xgettext may not 
> | handle such expressions properly the way it handles having just a single 
> | string as parameter.
> 
> OK, thanks the explanation.
> 
> Do you think the same issue arise with diagnostic_set_info,
> diagnostic_append_note?

I don't see any problematic calls to those functions with this sort of 
conditional expression.