Hi,
Thanks for your help Gaby, in particular about the MS extension which I had overlooked completely (as any hard-code Linux guy would ;). Anyway, seriously, I'll try to come up with an improved proposal over the next days.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 '&'.
Thanks again, Paolo.
