This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, Oct 19, 2011 at 7:47 PM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> 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.
>

Another acceptable fix is to
  -- leave the current diagnostic as is if -fms-extensions
  -- suggest '()' is member function
  -- otherwise suggest '&'.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]