On 10/12/2020 18:39, David Malcolm wrote:
On Fri, 2020-12-04 at 10:58 +0100, Erick Ochoa wrote:
+         // Anonymous fields? (Which the record can be!).
+           warning (OPT_Wdfa, "RECORD_TYPE %qE has dead field %qE in LTO.\n",
+               record, field);

Others have pointed out that -Wdfa isn't a good name for the warning, I
like their suggestions.

A few other nitpicks on this:

- "RECORD_TYPE" is an implementation detail of GCC.  Diagnostics should
be worded in terms of the user’s source code, and the source language,
rather than GCC’s own implementation details.

- "dead field" feels like jargon to me.

How about:
   field 'foo' in 'struct bar' is never used [-Wunused-field]
or somesuch?

- The "in LTO" in the message seems like a redundant implementation
detail to me.

- "warning" will implicitly use the global "input_location" as the
location of the diagnostic.  Better would be to use "warning_at" with
the location of the field's declaration.  I think you can get this via
DECL_SOURCE_LOCATION () on the FIELD_DECL.


See also:
   https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html


Thank you everyone for your input. I will change this in the next version of the patchset. I am already fixing some errors I found during the weekend.

I originally avoided the printing the field name because I believe that some fields may be anonymous and I was unsure on how to print them.

I also avoided to use warning_at because originally I didn't know where the location for the warning would be appropriate. (In the declaration of the structure? What if there are writes to the field but never reads? Currently these are marked as dead as well.)

"In LTO" is added in the warning because at the source level, if one were to remove the field from the declaration and compile, there might be compile time errors because dead code elimination has not yet been run and there might be references to these fields. (They're only truly dead after dead code elimination.)

At the moment, my next step will be to review the guidelines for diagnostics and think about how to improve the current diagnostic. If you have more suggestions, please do let me know!

-Erick



Hope this is constructive
Dave

Reply via email to