Re: [llvm-dev] Detecting invalid functions of template specialisations

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: [llvm-dev] Detecting invalid functions of template specialisations

Robinson, Paul via cfe-dev
fwd to cfe-dev list.

2017-11-24 19:34 GMT+08:00 Dimitar Dobrev via llvm-dev <[hidden email]>:
Hello all.

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

I think that if the found function is invalid
(clang::Decl::isInvalidDecl()) this case should fall through to .

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 , 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:


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.

LLVM Developers mailing list
[hidden email]

Wei-Ren Chen (陳韋任)

cfe-dev mailing list
[hidden email]