Re: [pph] Fix method lookups (part 1) (issue4997042)

[Gabriel Charette <gcharette1 at gmail dot com>]

On Fri, Sep 9, 2011 at 4:37 PM, Diego Novillo <dnovillo@google.com> wrote:
>
> The main problem fixed here is that name lookups for class methods
> uses a binary search that assumes that the methods in
> CLASSTYPE_METHOD_VEC are sorted by pointer value.
>
> Since the reader typically allocates trees in a different pattern than
> the writer, it is common for the symbols in the vector to have
> different pointer values, so the order used by the writer is different
> than the reader.
>
> This was causing us to fail name lookups when generating the pph image
> for x6dynarray5.h and x6dynarray6.h.
>
> To fix this, I am making finish_struct_methods an extern function and
> calling it after reading a type that has a CLASSTYPE_METHOD_VEC.
>
> This exposed another failure that was simple enough to roll in
> together with this patch. ÂWe should not emit preloaded symbols when
> writing the names in the global namespace. ÂThis was causing a
> DECL_CHAIN cycle. ÂI added a new filter PPHF_NO_PREFS to skip the
> preloaded symbols when needed.
>

The loop in the DECL_CHAIN in x6dynarray5 was already there before.
This is why I had introduced the preloaded cache to do something along
those lines.

However I don't think simply filtering it out is sufficient in this
case. The reason there is a loop in this case if I recall correctly is
that "new" (amongst others) is overloaded in #include <new>. i.e. it
used to be filtered by PPHF_NO_BUILTINS, but the overload clears the
BUILTIN_LOCATION and thus the builtins filter doesn't filter new out
anymore (but the pointer itself didn't change, so yes filtering PREFs
WILL filter it out, but it will also ignore the overload and load the
old PREF on the way in, not the new "new" overloaded by the include).

By not filtering it out however we create a loop: as, since the
pointer itself hasn't changed, we output the PREF (because we get a
preloaded cache hit), so either way we loose the overload and if not
filtering it out create a loop on the way in, but what we really need
is to output the overload and correctly re-push_overloaded_decl (or
something that has the same effect) on the way in.

Anyways, just can't help it, but keep reading all the patches coming in :)!

Cheers,
Gab