Re: [C++ Patch] PR 48630 (PR 31423)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Wed, Oct 19, 2011 at 7:09 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 10/20/2011 02:00 AM, Gabriel Dos Reis wrote:
>>
>> I believe the effect of your new patch is that if will
>> always emit the suggest "did you forget "()"?" for member functions,
>> even in the case where the current suggestion is correct.
>> Using the type context would prevent that regression.
>
> If you could give some guidance about the way to implement this, I may try
> over the next few days, otherwise probably I will have to give up for now (I
> assigned myself other PRs already), but it would be a pity, this PR has been
> reported 2 times by different people, apparently it's quite misleading.
> Anyway, I'm not assigned to the bug, even if I will not be able to actually
> help, it would be nice if you could attach to the audit trail a couple of
> nasty examples beyond what already considered in the analyses therein (both
> PRs)
>
> Thanks!
> Paolo.
>


I think I made a suggestion in my previous message:
  -- decouple this particular diagnostic from 'incomplete type' error.
      Because it has nothing to do with incomplete type error.

 -- once the diagnostic is decoupled, you could "grep" for all the
    places where cxx_incomplete_type_error or cxx_incomplete_type_diagnostic
    is called from.


My comments weren't in terms of "owenership" of the PR.

I would not necessarily say that they are nasty cases.

I know you don't like history but I believe it is important to
understand how the diagnostics came to be before fixing
them to prevent regressions -- or to purposefully break with
the past.

The reason why we have this suggestion in the first place is
because g++ supports the MS extension known as "bound member
function", e.g. something like &c.f, where c is an object and f is a
non-static member function.  It isn't ISO C++, but it is GNU C++
wth -fms-extensions.  A simple testcase is

struct C {
   int f() { return 1; }
   int g() { return 2; }
};

int f(C&c) {
   return &c.g == &c.f;
}


If you compile that program fragment with -fms-extensions, g++ will
accept it.  If you remove one of the '&', you get the diagnostic that
you want to fix.  You realize that if you use '()', you get another
type incompatible error, but not if you use '&' as suggested.

So the diagnostic could use both type context and test for -fms-extensions.

PS: more than a decade ago, I suggested removing this but people disagreed.