c++: Hash table iteration for namespace-member spelling suggestions

[Jakub Jelinek]

On Mon, Oct 05, 2020 at 11:48:32AM +0200, Christophe Lyon via Gcc-patches wrote:
> > For 'no such binding' errors, we iterate over binding levels to find a
> > close match.  At the namespace level we were using DECL_ANTICIPATED to
> > skip undeclared builtins.  But (a) there are other unnameable things
> > there and (b) decl-anticipated is about to go away.  This changes the
> > namespace scanning to iterate over the hash table, and look at
> > non-hidden bindings.  This does mean we look at fewer strings
> > (hurrarh), but the order we meet them is somewhat 'random'.  Our
> > distance measure is not very fine grained, and a couple of testcases
> > change their suggestion.  I notice for the c/c++ common one, we now
> > match the output of the C compiler.  For the other one we think 'int'
> > and 'int64_t' have the same distance from 'int64', and now meet the
> > former first.  That's a little unfortunate.  If it's too problematic I
> > suppose we could sort the strings via an intermediate array before
> > measuring distance.
> >
> >          gcc/cp/
> >          * name-lookup.c (consider_decl): New, broken out of ...
> >          (consider_binding_level): ... here.  Iterate the hash table for
> >          namespace bindings.
> >          gcc/testsuite/
> >          * c-c++-common/spellcheck-reserved.c: Adjust diagnostic.
> >          * g++.dg/spellcheck-typenames.C: Adjust diagnostic.
> >
> > pushing to trunk
> >
> 
> Hi Nathan,
> 
> This is causing regressions on aarch64 and arm when using
> -mfloat-abi=hard (or configuring for arm-linux-gnueabihf).
> The logs says:
> FAIL: c-c++-common/spellcheck-reserved.c  -std=gnu++98 (test for excess errors)
> Excess errors:
> /gcc/testsuite/c-c++-common/spellcheck-reserved.c:31:3: error:
> '__builtin_strtchr' was not declared in this scope; did you mean
> '__builtin_strrchr'?

Yeah, ditto on i686-linux (but passes on x86_64-linux).
Iterating over a hash table is fine, but we should not generate random
results.  So, the function that decides what is better and worse needs to
have some additional rules, so that no two different decl names are considered
equal.  Whether it is DECL_UID, or string length of the name, or some hash
of the string characters doesn't matter that much.

	Jakub