https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72786
--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks for filing this.
A two-liner fix for this would be to detect in
best_match<G, C>::get_best_meaningful_candidate
if m_best_distance is 0, and if so return NULL, i.e. to not give a suggestion
if somehow we have suggestion of the goal string. Doing so would give this
output:
pr72786.C:2:30: error: ‘OVERRIDE’ does not name a type
virtual void clone() const OVERRIDE { }
^~~~~~~~
OVERRIDE
(i.e. no suggestion).
It would be nice to offer a better error message to the user about the macro
ordering.
It's easy to detect in both C and C++'s implementation of lookup_name_fuzzy if
we have a macro equal to the goal string (look for the best_macro_match having
a best distance of 0). If we see this , and the macro defn happens after the
macro usage site, we can suppress the bogus hint, and potentially add a note
or two, giving something like this:
pr72786.C:2:30: error: ‘OVERRIDE’ does not name a type
virtual void clone() const OVERRIDE { }
^~~~~~~~
OVERRIDE
pr72786.C:2:30: note: the macro ‘OVERRIDE’ had not yet been defined
pr72786.C:4:8: note: it was later defined here:
#define OVERRIDE override
^~~~~~~~
or somesuch wording (presumably the 2nd note would typically be in some header
file, and thus typically show the usual info about "in file included from"
etc).
Doing this consistently would require updating all call sites of
lookup_name_fuzzy in the C and C++ frontends, perhaps to use some new common
interface for issuing a diagnostic with an optional suggestion
e.g. have lookup_name_fuzzy return some "class name_hint" or somesuch, with
methods for emitting the appropriate diagnostics.
