[llvm-dev] Detecting invalid functions of template specialisations
Dimitar Dobrev via llvm-dev
llvm-dev at lists.llvm.org
Fri Nov 24 03:34:52 PST 2017
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.
More information about the llvm-dev
mailing list