[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #15 from Martin Sebor --- Fixed in r271971.
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
--- Comment #14 from rguenther at suse dot de ---
On Sat, 11 May 2019, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
>
> --- Comment #13 from Martin Sebor ---
> I had started by doing that but gave up when I noticed that there are lots of
> them, some like this:
>
> if (TREE_CODE (expr) == REALPART_EXPR
> || TREE_CODE (expr) == IMAGPART_EXPR
> || TREE_CODE (expr) == BIT_FIELD_REF)
> {
> tree op = TREE_OPERAND (expr, 0);
> if (!is_gimple_reg_type (TREE_TYPE (expr)))
> {
> error ("non-scalar BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR");
> return true;
> }
>
> some like this:
>
> case VEC_UNPACK_HI_EXPR:
> case VEC_UNPACK_LO_EXPR:
> case VEC_UNPACK_FLOAT_HI_EXPR:
> case VEC_UNPACK_FLOAT_LO_EXPR:
> case VEC_UNPACK_FIX_TRUNC_HI_EXPR:
> case VEC_UNPACK_FIX_TRUNC_LO_EXPR:
> ...
> error ("type mismatch in vector unpack expression");
>
> that avoid mentioning the exact code altogether, or like this:
>
> case LSHIFT_EXPR:
> case RSHIFT_EXPR:
> case LROTATE_EXPR:
> case RROTATE_EXPR:
> ...
> error ("type mismatch in shift expression");
>
> and some even that "lie" for the sake of brevity. It would be nice to always
> mention the exact code.
Ah, for these cases it looks an OK change.
> But I can save the result of get_tree_code_name (rhs_code) and use that
> instead
> of calling it repeatedly. (My initial approach was to add a new directive to
> the generic pretty-printer but, sadly, get_tree_code_name is defined in tree.c
> and not available there so I'd have had to duplicate the directive code for
> each front-end and for the middle-end. That seems like too much hassle.)
No, I just thought I saw (the first) case where your replacement
was at a point the tree code was exactly known at compile-time?
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
--- Comment #13 from Martin Sebor ---
I had started by doing that but gave up when I noticed that there are lots of
them, some like this:
if (TREE_CODE (expr) == REALPART_EXPR
|| TREE_CODE (expr) == IMAGPART_EXPR
|| TREE_CODE (expr) == BIT_FIELD_REF)
{
tree op = TREE_OPERAND (expr, 0);
if (!is_gimple_reg_type (TREE_TYPE (expr)))
{
error ("non-scalar BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR");
return true;
}
some like this:
case VEC_UNPACK_HI_EXPR:
case VEC_UNPACK_LO_EXPR:
case VEC_UNPACK_FLOAT_HI_EXPR:
case VEC_UNPACK_FLOAT_LO_EXPR:
case VEC_UNPACK_FIX_TRUNC_HI_EXPR:
case VEC_UNPACK_FIX_TRUNC_LO_EXPR:
...
error ("type mismatch in vector unpack expression");
that avoid mentioning the exact code altogether, or like this:
case LSHIFT_EXPR:
case RSHIFT_EXPR:
case LROTATE_EXPR:
case RROTATE_EXPR:
...
error ("type mismatch in shift expression");
and some even that "lie" for the sake of brevity. It would be nice to always
mention the exact code.
But I can save the result of get_tree_code_name (rhs_code) and use that instead
of calling it repeatedly. (My initial approach was to add a new directive to
the generic pretty-printer but, sadly, get_tree_code_name is defined in tree.c
and not available there so I'd have had to duplicate the directive code for
each front-end and for the middle-end. That seems like too much hassle.)
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
--- Comment #12 from rguenther at suse dot de ---
On May 10, 2019 10:34:03 PM GMT+02:00, "msebor at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
>
>Martin Sebor changed:
>
> What|Removed |Added
>
> Status|NEW |ASSIGNED
> Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
>
>--- Comment #11 from Martin Sebor ---
>I'm replacing all the tree codes with %qs and get_tree_code_name
>(TREE_CODE
>(expr)), like so:
>
>@@ -3072,13 +3073,15 @@ verify_types_in_gimple_reference (tree expr,
>bool
>requir
>e_lvalue)
>size))
>{
> error ("mode size of non-integral result does not "
>-"match field size of BIT_FIELD_REF");
>+"match field size of %qs",
>+get_tree_code_name (TREE_CODE (expr)));
> return true;
>}
> if (INTEGRAL_TYPE_P (TREE_TYPE (op))
> && !type_has_mode_precision_p (TREE_TYPE (op)))
>{
>- error ("BIT_FIELD_REF of non-mode-precision operand");
>+ error ("%qs of non-mode-precision operand",
>+get_tree_code_name (TREE_CODE (expr)));
> return true;
>}
> if (!AGGREGATE_TYPE_P (TREE_TYPE (op))
That looks excessive for code size. Why not just quote the names appropriately?
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #11 from Martin Sebor ---
I'm replacing all the tree codes with %qs and get_tree_code_name (TREE_CODE
(expr)), like so:
@@ -3072,13 +3073,15 @@ verify_types_in_gimple_reference (tree expr, bool
requir
e_lvalue)
size))
{
error ("mode size of non-integral result does not "
-"match field size of BIT_FIELD_REF");
+"match field size of %qs",
+get_tree_code_name (TREE_CODE (expr)));
return true;
}
if (INTEGRAL_TYPE_P (TREE_TYPE (op))
&& !type_has_mode_precision_p (TREE_TYPE (op)))
{
- error ("BIT_FIELD_REF of non-mode-precision operand");
+ error ("%qs of non-mode-precision operand",
+get_tree_code_name (TREE_CODE (expr)));
return true;
}
if (!AGGREGATE_TYPE_P (TREE_TYPE (op))
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149 --- Comment #10 from Roland Illig --- (In reply to Richard Biener from comment #9) > IMHO the error calls in our IL checkers are abusive, they could have been > simple dumps to stderr for example. It was just "convenient" to use > a disagnostic reporting routine here (largely historically convenient). I can totally understand that since I was in the same situation some days ago. In a linter I maintain I was so used to issuing diagnostics that I didn't notice that I/O errors are something different and that there need to be separate functions for reporting these.
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
Richard Biener changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #9 from Richard Biener ---
(In reply to Martin Sebor from comment #8)
> (In reply to Richard Biener from comment #6)
>
> The trouble is that there is no way to tell whether
>
> error ("BIT_FIELD_REF of non-mode-precision operand");
>
> is a user-facing error or an internal error not meant to be translated. The
> #pragma GCC diagnostic ignored "-Wformat-diag" solution suppresses the
> warning but won't help translators. The only ways to deal with that that
> comes to mind are either a new inernal_error_and_continue() function or
> some special annotation in the format string to make it clear both to
> -Wformat-diag and to translators that the string isn't meant to be
> translated (or checked for translation problems). Is there a preference for
> one or other approach? Or some other solution I'm not thinking of?
Ah, so Roland pointed out the bug this was discussed. I think his approach
is reasonable (keep the original message but prefix it with a localized
prefix). I think it would be useful for translators to know whether
they are dealing with "internal" errors or regular errors.
IMHO the error calls in our IL checkers are abusive, they could have been
simple dumps to stderr for example. It was just "convenient" to use
a disagnostic reporting routine here (largely historically convenient).
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
--- Comment #8 from Martin Sebor ---
(In reply to Richard Biener from comment #6)
The trouble is that there is no way to tell whether
error ("BIT_FIELD_REF of non-mode-precision operand");
is a user-facing error or an internal error not meant to be translated. The
#pragma GCC diagnostic ignored "-Wformat-diag" solution suppresses the warning
but won't help translators. The only ways to deal with that that comes to mind
are either a new inernal_error_and_continue() function or some special
annotation in the format string to make it clear both to -Wformat-diag and to
translators that the string isn't meant to be translated (or checked for
translation problems). Is there a preference for one or other approach? Or
some other solution I'm not thinking of?
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149 --- Comment #7 from Roland Illig --- (In reply to Richard Biener from comment #6) > IMNSHO the IL checker "errors" should continue to use GCC terms since they > check the GIMPLE intermediate language. They also shouldn't necessarily be > translated (though they may end up user-facing if they turn on -fchecking). If you want to join the discussion about whether internal compiler errors should be translated, I'm happy to invite you to bug 80055. ;)
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149 --- Comment #6 from Richard Biener --- IMNSHO the IL checker "errors" should continue to use GCC terms since they check the GIMPLE intermediate language. They also shouldn't necessarily be translated (though they may end up user-facing if they turn on -fchecking).
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149 --- Comment #5 from Martin Sebor --- *** Bug 79878 has been marked as a duplicate of this bug. ***
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-04-18
CC||msebor at gcc dot gnu.org
Component|tree-optimization |translation
Ever confirmed|0 |1
--- Comment #4 from Martin Sebor ---
FWIW, I'm working on a -Wformat enhancement to detect this and some of the
other translation problems you have pointed out. I'm also going through
gcc.pot and looking for patterns like this to detect myself but having them
pointed out by someone actually doing the translation is very helpful. Thank
you!
As for this specific error (and others like it) in tree-cfg.c and a few other
files, they are issued for failures detected by internal consistency checks
that ultimately do trigger an internal compiler error. In my patch I disable
the detection of these problems via #pragma GCC diagnostic ignored
"-Wformat-diag" but another option is to simply fix them:
error ("%qs of non-mode-precision operand", "BIT_FIELD_REF");
The challenge with doing it that it would changing a fair number of messages
and in some cases, make the format strings look pretty cryptic (by replacing
multiple strings with %s directives).
