On 6/21/19 4:16 PM, Ian Lance Taylor wrote:
On Wed, Jun 19, 2019 at 12:49 PM Martin Sebor <mse...@gmail.com> wrote:
gcc-wformat-diag-checker.diff
gcc/c-family/ChangeLog:
* c-format.c (function_format_info::format_type): Adjust type.
(function_format_info::is_raw): New member.
(decode_format_type): Adjust signature. Handle "raw" diag
attributes.
(decode_format_attr): Adjust call to decode_format_type.
Avoid a redundant call to convert_format_name_to_system_name.
Avoid abbreviating the word "arguments" in a diagnostic.
(format_warning_substr): New function.
(avoid_dollar_number): Quote dollar sign in a diagnostic.
(finish_dollar_format_checking): Same.
(check_format_info): Same.
(struct baltoks_t): New.
(c_opers, c_keywords, cxx_keywords, badwords, contrs): New arrays.
(maybe_diag_unbalanced_tokens, check_tokens, check_plain): New
functions.
(check_format_info_main): Call check_plain. Use baltoks_t. Call
maybe_diag_unbalanced_tokens.
(handle_format_attribute): Spell out the word "arguments" in
a diagnostic.
I want to mention that this is causing some false positive warnings
when building the Go frontend (and a number of true positive warnings
as well). The false positives don't break the build or anything, but
it would be nice to avoid them.
I meant to bring this up with you and ask how to go about cleaning
this up but forgot. Thanks for reminding me!
The escape analysis pass is emitting a format intended for debugging
the compiler itself, when using -fgo-debug-escape. It produces
warnings like the following. This output is fine.
../../gccgo/gcc/go/gofrontend/escape.cc: In member function ‘virtual
int Escape_analysis_assign::statement(Block*, size_t*, Statement*)’:
../../gccgo/gcc/go/gofrontend/escape.cc:1336:33: warning: spurious
leading punctuation sequence ‘[’ in format [-Wformat-diag]
1336 | go_inform(s->location(), "[%d] %s esc: %s",
| ^
../../gccgo/gcc/go/gofrontend/escape.cc: In member function ‘void
Escape_analysis_assign::call(Call_expression*)’:
../../gccgo/gcc/go/gofrontend/escape.cc:1964:17: warning: unquoted
operator ‘::’ in format [-Wformat-diag]
1964 | "esccall:: indirect call <- %s, untracked",
| ^~
In other parts of GCC I suppressed these kinds of diagnostics via
#pragma GCC diagnostic ignored. In the middle-end, these messages
are almost all the result of "misusing" the diagnostic machinery
to report internal errors that aren't meant to be translated or
follow the usual diagnostic guidelines.
Using warning suppression isn't ideal because it doesn't help
translators. A better solution would be to mark them up to make
it clear that they don't need to be translated and should be
exempted from the checking. One solution might be to introduce
another diagnostic function for that, along with an attribute.
Or a special new directive to introduce the messages with, say,
for example %! or some such, at the beginning of the format string.
I see warnings saying that the keyword "float" should be quoted. But
"float" is not a keyword in Go. For example, it would be pointless to
quote float here:
../../gccgo/gcc/go/gofrontend/expressions.cc: In member function ‘bool
Numeric_constant::check_float_type(Float_type*, bool, Location)’:
../../gccgo/gcc/go/gofrontend/expressions.cc:18980:68: warning:
unquoted keyword ‘float’ in format [-Wformat-diag]
18980 | go_error_at(location, "complex constant
truncated to float");
I would suggest to change "float" to "floating" here.
What is the best way to avoid these warnings when compiling the Go frontend?
It looks like most of the unhelpful warnings in the Go front end
are in escape.cc. Until we come up with a robust solution I would
suggest to suppress those using the #pragma.
Most of the rest seem justified to me and worth cleaning up. Let
me know if you agree and if you'd like my help with it.
Martin
