I think this is great. My overall question is: is the new BLT
representation available in the middle-end? If not, do you
have plans to make it available? (I think it might be especially
useful there, to either accurately highlight the source of
a problem when it's far removed from the problem site, or to
track the flow of data from its source to the sink.)
=====================
(b) Examples of usage
=====================
Patches 6-10 in the kit update various diagnostics to use
the improved location information where available:
* C and C++: highlighting the pertinent parameter of a function
decl when there's a mismatched type in a call
Very nice!
* C and C++: highlighting the return type in the function defn
when compaining about mismatch in the body (e.g. highlighting
the "void" when we see a "return EXPR;" within a void function).
* C++: add a fix-it hint to -Wsuggest-override
I have plenty of ideas for other uses of this infrastructure
(but which aren't implemented yet), e.g.:
* C++: highlight the "const" token (or suggest a fix-it hint)
when you have a missing "const" on the *definition* of a member
function that was declared as "const" (I make this mistake
all the time).
* C++: add a fix-it hint to -Wsuggest-final-methods
To answer your call for other ideas below: There are other
suggestions that GCC could offer to help improve code, including
* to add the const qualifier to function pointer and reference
arguments (including member functions)
* to add restrict where appropriate (especially to const pointer
and reference arguments)
* to delete or default the default copy ctor or copy assignment
operator if/when it would benefit
* to help highlight how to optimize data layout (with a new
hypothetical feature that offered suggestions to reorder
struct or class members for space efficiency or data
locality)
* highlight bogus attributes
This would be very nice. The diagnostics in this area are weak
to put it mildly, and the highlighting is completely bogus. It
would be great to also be able to highlight attribute operands.
* add fix-it hints suggesting missing attributes
...etc, plus those "cousins of a compiler" ideas mentioned above.
Any other ideas?
This may be outside the scope of your work but when a declaration
is found to conflict in some way with one seen earlier on in a file,
it would be great to be able to point to the actual source of the
conflict rather than to the immediately preceding declaration as
a whole. As in:
int __attribute__ ((noinline)) foo (int);
int foo (int);
int __attribute ((always_inline)) foo (int);
x.c:5:35: warning: declaration of ‘int foo(int)’ with attribute
‘always_inline’ follows declaration with attribute ‘noinline’ [-Wattributes]
int __attribute ((always_inline)) foo (int);
^~~
Rather than printing a note like this:
x.c:3:5: note: previous declaration of ‘int foo(int)’ was here
int foo (int);
^~~
print this:
x.c:1:5: note: previous declaration of ‘int foo(int)’ was here
int __attribute__ ((noinline)) foo (int);
^~~
(preferably with the attribute underlined).
I'm sure there are many others.
Martin
