Hi,
On 08/06/2013 04:57 AM, Jason Merrill wrote:
On 08/05/2013 06:46 PM, Paolo Carlini wrote:
and after this comment, both pairs of qualify_lookup are called in that
order. Thus I started seriously suspecting that something may be wrong
in the if-else above, that is, that we really want something with
iter->type *before* iter->value there too: the attached patchlet p works
for the testcase and passes bootstrap & test. Does it make sense to you?
Yes.
Ok, good.
Final observation: in many cases, like for example, variants of the
testcase with one less data member, what happens is that iter->type and
iter->value are *both* the same variant of the TYPE_DECL Bar, the one
which is fine, has DECL_IMPLICIT_TYPEDEF_P set.
That's strange. I would expect that to mean that we don't properly
give an error for a Bar data member declared after the typedef.
You mean something like this?
class Foo
{
int u, v, w;//, x;
typedef struct Bar { } Bar;
Bar bar;
virtual void foo(void) {
struct Bar bar;
}
};
after the patch we accept it, while we rejected it before. Current clang
and icc also accept it. Note however, that in the above iter->type and
iter->value are different, usual story. Same with w too commented out or
neither. I haven't been able to construct a testcase following by and
large your recipe where iter->type == iter->value. In short alternating
data members and TYPE_DECLs also makes iter->type != iter->value, thus
we want to check them in the proper order in such cases too.
Do you have more testcases in mind? (otherwise I would add the above too)
Thanks,
Paolo.
