Original bug is observed on https://bugs.gentoo.org/739036 where source-highlight was buildable by g++-10 and failed b clang++-10. Reduced example: namespace a { enum c { d }; class e { public: e(c); }; }; // namespace a a::e f(a::e(a::d)); gcc succeeds to build the example, clang fails: $ g++-10.2.0 -std=c++14 -c -o test_exception_main.o bug.cpp && echo OK || echo FAIL OK $ clang++-10 -std=c++14 -c -o test_exception_main.o bug.cpp && echo OK || echo FAIL bug.cpp:10:16: error: parameter declarator cannot be qualified a::e f(a::e(a::d)); ~~~^ 1 error generated. FAIL gcc bug, clang bug or known ambiguity? Looks like clang does not see a::d as an enum value.
This looks like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86564
Yes, weird though this might be, the standard rules say that this disambiguates as a function declaration whose parameter is named a::d (with redundant parentheses around the parameter name), just like: a::e f(a::e a::d); ... which is invalid because the name of the parameter can't be qualified, but that's a semantic restriction that's not taken into account by disambiguation. MSVC and EDG agree that this testcase is invalid for the same reason Clang diagnoses it, so it looks like it's only GCC that uses the presence of the qualifier for disambiguation.
Oh, that's very non-intuitive. Thank you!