[cfe-dev] libclang: Resolving dependent names

[Jusufadis Bakamovic via cfe-dev]

Hi Roger,

Thanks for your effort. Your example perfectly made clear the quote from
the standard.

I do realize that information for dependent names is limited due to the two
phase lookup which needs to take place in order to get a full picture. But
I was puzzled by the fact that we can (partially) extract more information
by inspecting the AST. I.e. if we stumble upon a dependent-name node which
happens to be a child of call-expression node then it certainly encodes an
information that dependent-name node comprises of a function call (or a
functor which boils down to the operator() call).

So, it looks like that some additional information without going to the
second phase lookup can be made available. It may be a good candidate for
libclang interface extension.

Cheers,
Adi


On 24 January 2017 at 11:08, Roger Ferrer Ibanez <Roger.FerrerIbanez at arm.com
> wrote:

> Hi,
>
>
>
> I’m not an expert in clang internals but I can understand why the
> information it has at this point is much more limited. Consider the
> following example
>
>
>
> --example.cc
>
> template <typename T>
>
> struct A
>
> {
>    void foo(int);
>
> };
>
> template <typename T>
> struct A<T*>
> {
>   struct B { void operator()(int); };
>   B foo;
> };
>
> template <typename T>
> void foo()
> {
>   A<T> a;
>   a.foo(3);
> }
>
>
>
> template void foo<int>(); // first case
> template void foo<int*>(); // second case
>
> --end of example.cc
>
>
>
> That “a.foo(3)” will either be “a.foo(3)” in the first case and
> “a.foo.operator()(3)”  in the second case. In the first case “foo” is a
> member function and in the second one is a data member.
>
>
>
> Hope this helps.
>
>
>
> Kind regards,
>
> Roger
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170125/c0ed753f/attachment.html>