Created attachment 36251 [details] Example program to demonstrate missing warning. See example program in attachment. Crucial steps to reproduce code that exhibits the bug: 'MyDerived' defines 'virtual frob(int, int)', and hides the non-virtual 'frob(int)' of 'MyBase'. Evidence that there is actually some "hiding" going on: - Empirical: If we change 'frob(int)' of 'MyBase' to virtual, then g++ issues a warning. - Reported on stackoverflow, other people ran into that issue before me: http://stackoverflow.com/a/6035884/3070326 Expected behaviour from g++: Warn that 'MyDerived::frob(int,int)' hides 'MyBase::frob(int)', although this might be unintuitive for C++ newbies. (Just like the warning for "a < b < c".) Actual behaviour: 'frob(int)' is inaccessible when the static type is 'MyDerived'. This means one of the following happens: - If 'frob(int)' is not called, then g++ silently ignores the situation. BAD! I want a warning, telling me that 'frob(int, int)' is at fault. (Example: Attached file, verbatim) - Otherwise, g++ only lists 'MyDerived::frob(int, int)' as candidate. BAD! I want another candidate ('MyBase::frob(int)') with the explanation that overload resolution does not operate across namespaces. (Example: Attached file, with the 'derived.frob(23);' uncommented.) Meta-info: "gcc version 4.9.3 (Debian 4.9.3-3) " As there is no similar bug report, I assume it has not been fixed by a more recent version anyway.
-Woverloaded-virtual warns when a function hides a virtual, which is not the case here. The function that is hidden is non-virtual. I don't think this warrants a warning, but the error when trying to call derived.frob(23) could be more helpful. Clang says "did you mean 'MyFrob::frob'?" file.cpp:23:10: error: too few arguments to function call, expected 2, have 1; did you mean 'MyBase::frob'? derived.frob(23); ^~~~ MyBase::frob file.cpp:11:7: note: 'MyBase::frob' declared here void frob(int a) { cout << "MyBase::frob(int), forwarding:" << endl; frob(a, 42); } ^ 1 error generated.
I see the hiding as a potential "design error", or however that is called: A shortcoming of the way the methods were named. Clang 4.5 does not warn until there is such a "bad" call. Is there a compiler + flag combination that can provide such a warning?
Dup. *** This bug has been marked as a duplicate of bug 20710 ***