Re: [committed] Add support for grouping of related diagnostics (PR other/84889)
On Mon, Aug 20, 2018 at 11:10 PM David Malcolm wrote:
>
> We often emit logically-related groups of diagnostics.
>
> A relatively simple case is this:
>
> if (warning_at (body_loc, OPT_Wmultistatement_macros,
> "macro expands to multiple statements"))
> inform (guard_loc, "some parts of macro expansion are not guarded by "
> "this %qs clause", guard_tinfo_to_string (keyword));
>
> where the "note" diagnostic issued by the "inform" call
> is guarded by the -Wmultistatement_macros warning.
>
> More complicated examples can be seen in the C++ frontend,
> where e.g. print_z_candidates can lead to numerous "note"
> diagnostics being emitted.
>
> I'm looking at various ways to improve how we handle such related
> diagnostics, but, prior to this patch, there was no explicit
> relationship between these diagnostics: the diagnostics subsystem
> had no way of "knowing" that these were related.
>
> This patch introduces a simple way to group the diagnostics:
> an auto_diagnostic_group class: all diagnostics emitted within
> the lifetime of an auto_diagnostic_group instance are logically
> grouped.
>
> Hence in the above example, the two diagnostics can be grouped
> by simply adding an auto_diagnostic_group instance:
>
> auto_diagnostic_group d;
> if (warning_at (body_loc, OPT_Wmultistatement_macros,
> "macro expands to multiple statements"))
> inform (guard_loc, "some parts of macro expansion are not guarded by "
> "this %qs clause", guard_tinfo_to_string (keyword));
>
> Some more awkard cases are of the form:
>
> if (some_condition
> && warning_at (...)
> && more_conditions)
> inform (...);
>
> which thus need restructuring to:
>
> if (some_condition)
> {
> auto_diagnostic_group d;
> warning_at (...);
> if (more_conditions)
> inform (...);
> }
>
> so that the lifetime of the auto_diagnostic_group groups the
> warning_at and the inform call.
>
> Nesting is handled by simply tracking a nesting depth within the
> diagnostic_context.: all diagnostics are treated as grouped until the
> final auto_diagnostic_group is popped.
>
> diagnostic.c uses this internally, so that all diagnostics are part of
> a group - those that are "by themselves" are treated as being part of
> a group with one element.
>
> The diagnostic_context gains optional callbacks for displaying the
> start of a group (when the first diagnostic is emitted within it), and
> the end of a group (for when the group was non-empty); these callbacks
> are unused by default, but a test plugin demonstrates them (and verifies
> that the machinery is working).
>
> As noted above, I'm looking at various ways to use the grouping to
> improve how we output the diagnostics.
>
> FWIW, I experimented with a more involved implementation, of the form:
>
> diagnostic_group d;
> if (d.warning_at (body_loc, OPT_Wmultistatement_macros,
> "macro expands to multiple statements"))
> d.inform (guard_loc, "some parts of macro expansion are not guarded by "
> "this %qs clause", guard_tinfo_to_string (keyword));
>
> which had the advantage of allowing auto-detection of the places where
> groups were needed (by converting ::warning_at's return type to bool),
> but it was a much more invasive patch, especially when dealing with
> the places in the C++ frontend that can emit numerous notes after
> an error or warning (and thus having to pass the group around)
> Hence I went with this simpler approach.
IMHO a shame because the
auto_diagnostic_group d;
stuff really looks unrelated and it's probably easy enough to not notice
errors with it.
I'd have used
if (diagnostic_group d = warning_at (...))
d.inform (...);
for the common idiom so we'd be able to elide the conditionals. That is
diagnostic_group initializes from a bool, converts to a bool and the
forwarder methods do nothing if it was initialized from false.
Richard.
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu; adds
> 4 PASS results to gcc.sum.
>
> Committed to trunk as r263675.
>
> gcc/c-family/ChangeLog:
> PR other/84889
> * c-attribs.c (common_handle_aligned_attribute): Add
> auto_diagnostic_group instance.
> * c-indentation.c (warn_for_misleading_indentation): Likewise.
> * c-opts.c (c_common_post_options): Likewise.
> * c-warn.c (warn_logical_not_parentheses): Likewise.
> (warn_duplicated_cond_add_or_warn): Likewise.
> (warn_for_multistatement_macros): Likewise.
>
> gcc/c/ChangeLog:
> PR other/84889
> * c-decl.c (pushtag): Add auto_diagnostic_group instance.
> (diagnose_mismatched_decls): Likewise, in various places.
> (warn_if_shadowing): Likewise.
> (implicit_decl_warning): Likewise.
> (implicitly_declare): Likewise.
> (undeclared_variable): Likewise.
> (declare_label): Likewise.
> (grokdec
[committed] Add support for grouping of related diagnostics (PR other/84889)
We often emit logically-related groups of diagnostics.
A relatively simple case is this:
if (warning_at (body_loc, OPT_Wmultistatement_macros,
"macro expands to multiple statements"))
inform (guard_loc, "some parts of macro expansion are not guarded by "
"this %qs clause", guard_tinfo_to_string (keyword));
where the "note" diagnostic issued by the "inform" call
is guarded by the -Wmultistatement_macros warning.
More complicated examples can be seen in the C++ frontend,
where e.g. print_z_candidates can lead to numerous "note"
diagnostics being emitted.
I'm looking at various ways to improve how we handle such related
diagnostics, but, prior to this patch, there was no explicit
relationship between these diagnostics: the diagnostics subsystem
had no way of "knowing" that these were related.
This patch introduces a simple way to group the diagnostics:
an auto_diagnostic_group class: all diagnostics emitted within
the lifetime of an auto_diagnostic_group instance are logically
grouped.
Hence in the above example, the two diagnostics can be grouped
by simply adding an auto_diagnostic_group instance:
auto_diagnostic_group d;
if (warning_at (body_loc, OPT_Wmultistatement_macros,
"macro expands to multiple statements"))
inform (guard_loc, "some parts of macro expansion are not guarded by "
"this %qs clause", guard_tinfo_to_string (keyword));
Some more awkard cases are of the form:
if (some_condition
&& warning_at (...)
&& more_conditions)
inform (...);
which thus need restructuring to:
if (some_condition)
{
auto_diagnostic_group d;
warning_at (...);
if (more_conditions)
inform (...);
}
so that the lifetime of the auto_diagnostic_group groups the
warning_at and the inform call.
Nesting is handled by simply tracking a nesting depth within the
diagnostic_context.: all diagnostics are treated as grouped until the
final auto_diagnostic_group is popped.
diagnostic.c uses this internally, so that all diagnostics are part of
a group - those that are "by themselves" are treated as being part of
a group with one element.
The diagnostic_context gains optional callbacks for displaying the
start of a group (when the first diagnostic is emitted within it), and
the end of a group (for when the group was non-empty); these callbacks
are unused by default, but a test plugin demonstrates them (and verifies
that the machinery is working).
As noted above, I'm looking at various ways to use the grouping to
improve how we output the diagnostics.
FWIW, I experimented with a more involved implementation, of the form:
diagnostic_group d;
if (d.warning_at (body_loc, OPT_Wmultistatement_macros,
"macro expands to multiple statements"))
d.inform (guard_loc, "some parts of macro expansion are not guarded by "
"this %qs clause", guard_tinfo_to_string (keyword));
which had the advantage of allowing auto-detection of the places where
groups were needed (by converting ::warning_at's return type to bool),
but it was a much more invasive patch, especially when dealing with
the places in the C++ frontend that can emit numerous notes after
an error or warning (and thus having to pass the group around)
Hence I went with this simpler approach.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu; adds
4 PASS results to gcc.sum.
Committed to trunk as r263675.
gcc/c-family/ChangeLog:
PR other/84889
* c-attribs.c (common_handle_aligned_attribute): Add
auto_diagnostic_group instance.
* c-indentation.c (warn_for_misleading_indentation): Likewise.
* c-opts.c (c_common_post_options): Likewise.
* c-warn.c (warn_logical_not_parentheses): Likewise.
(warn_duplicated_cond_add_or_warn): Likewise.
(warn_for_multistatement_macros): Likewise.
gcc/c/ChangeLog:
PR other/84889
* c-decl.c (pushtag): Add auto_diagnostic_group instance.
(diagnose_mismatched_decls): Likewise, in various places.
(warn_if_shadowing): Likewise.
(implicit_decl_warning): Likewise.
(implicitly_declare): Likewise.
(undeclared_variable): Likewise.
(declare_label): Likewise.
(grokdeclarator): Likewise.
(start_function): Likewise.
* c-parser.c (c_parser_declaration_or_fndef): Likewise.
(c_parser_parameter_declaration): Likewise.
(c_parser_binary_expression): Likewise.
* c-typeck.c (c_expr_sizeof_expr): Likewise.
(parser_build_binary_op): Likewise.
(build_unary_op): Likewise.
(error_init): Likewise.
(pedwarn_init): Likewise.
(warning_init): Likewise.
(convert_for_assignment): Likewise.
gcc/cp/ChangeLog:
PR other/84889
* call.c (build_user_type_conversion_1): Add auto_diagnostic_group
instance(s).
(print_error_for_call_failure): Likewise.
(build
