xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890]
Checks
Commit Message
Hi!
The translation PR complains that these 4 messages from xtensa-dynconfig.c
are marked in po/gcc.pot as c-format (which doesn't allow %qs) while they
should be gcc-internal-format.
The problem is in the manual translation of the strings with _(),
that should be both unnecessary because fatal_error invokes _() on its
argument already, but also incorrect for the above reason, for
gcc-internal-format strings one should use G_("...") instead if really
needed.
The following patch drops those _("..."), tested by regenerating po/gcc.pot
to see they are now gcc-internal-format, but not really tested on xtensa
target.
Ok for trunk?
BTW, why is the file using .c extension rather than .cc? Why isn't t-xtensa
using $(COMPILE) and $(POSTCOMPILE) to compile it like for most other
extra_objs on other targets? And, why does that file use <> style includes
of gcc internal headers rather than "" style which is used everywhere else
in gcc?
2023-02-23 Jakub Jelinek <jakub@redhat.com>
PR translation/108890
* config/xtensa/xtensa-dynconfig.c (xtensa_load_config): Drop _()s
around fatal_error format strings.
Jakub
Comments
Hi Jakub,
On Thu, Feb 23, 2023 at 2:34 AM Jakub Jelinek <jakub@redhat.com> wrote:
> The translation PR complains that these 4 messages from xtensa-dynconfig.c
> are marked in po/gcc.pot as c-format (which doesn't allow %qs) while they
> should be gcc-internal-format.
>
> The problem is in the manual translation of the strings with _(),
> that should be both unnecessary because fatal_error invokes _() on its
> argument already, but also incorrect for the above reason, for
> gcc-internal-format strings one should use G_("...") instead if really
> needed.
>
> The following patch drops those _("..."), tested by regenerating po/gcc.pot
> to see they are now gcc-internal-format, but not really tested on xtensa
> target.
>
> Ok for trunk?
Ok.
> BTW, why is the file using .c extension rather than .cc?
It was initially developed when backend code was still in .c
files and I failed to update this part during forward porting.
I'll fix it.
> Why isn't t-xtensa using $(COMPILE) and $(POSTCOMPILE)
> to compile it like for most other extra_objs on other targets?
> And, why does that file use <> style includes of gcc internal
> headers rather than "" style which is used everywhere else
> in gcc?
No real reason for either. I'll fix it.
Thanks for your review.
-- Max
@@ -87,14 +87,14 @@ const void *xtensa_load_config (const ch
if (!handle)
{
fatal_error (input_location,
- _("%qs is defined but could not be loaded: %s"),
+ "%qs is defined but could not be loaded: %s",
CONFIG_ENV_NAME, dlerror ());
exit (FATAL_EXIT_CODE);
}
if (dlsym (handle, "plugin_is_GPL_compatible") == NULL)
{
fatal_error (input_location,
- _("%qs plugin is not licensed under a GPL-compatible license"),
+ "%qs plugin is not licensed under a GPL-compatible license",
CONFIG_ENV_NAME);
exit (FATAL_EXIT_CODE);
}
@@ -111,7 +111,7 @@ const void *xtensa_load_config (const ch
return no_name_def;
fatal_error (input_location,
- _("%qs is loaded but symbol %qs is not found: %s"),
+ "%qs is loaded but symbol %qs is not found: %s",
CONFIG_ENV_NAME, name, dlerror ());
exit (FATAL_EXIT_CODE);
}
@@ -125,7 +125,7 @@ const void *xtensa_load_config (const ch
if (path)
{
fatal_error (input_location,
- _("%qs is defined but plugin support is disabled"),
+ "%qs is defined but plugin support is disabled",
CONFIG_ENV_NAME);
exit (FATAL_EXIT_CODE);
}