llvm dev - Nov 2017 - Detecting invalid functions of template specialisations

Hello all.

I need your advice about a fix I am thinking about. See this code:

https://clang.llvm.org/doxygen/SemaOverload_8cpp_source.html#l12230

I think that if the found function is invalid 
(clang::Decl::isInvalidDecl()) this case should fall through to 
https://clang.llvm.org/doxygen/SemaOverload_8cpp_source.html#l12338 .

I am afraid I don’t know enough about the code of Clang and about 
compilers in general in order to think of a test myself. Instead, I 
could explain the problem I have and why I think something like this 
would help.

So, I work on https://github.com/mono/CppSharp , it’s a generator for 
language bindings to C++.

I need to get symbols of template specialisations so that I can compile 
them and invoke them from the target language. So I parse the input 
headers and use the Clang API to instantiate each specialisation I need:

Sema::InstantiateClassTemplateSpecialization

However, in many cases functions of specialisations are invalid. For 
example, the body of the templated function uses == while the T type 
argument does not support this operator. In order to find such 
functions, I use a custom DiagnosticConsumer combined with 
Sema::InstantiateFunctionDefinition for each function.

I am now going to explain the actual problem.
Some of these functions are inlined and use each other. A typical 
example is != which uses == internally, as in != { return !==; }. Let’s 
say the == is invalid. InstantiateFunctionDefinition detects that but it 
adds the == as a valid overload anyway. So when the != is parsed, Clang 
says: I have found a valid overload for the == inside and I am returning 
it so there’s no error in this function.
This problem also affects your stack traces because they show the CPP 
the == was originally requested from but do now show it for the !=.

Please share your opinions about the fix I have suggested and about the 
problem in general.