Finding CXFiles across different TUs

Is there a fast way in libclang to find CXFiles across different TUs other
then getting the string name (clang_getFileName) of a CXFile and
string-comparing it with the string name of all the other CXFiles included
in a different TU?

bad way:
fileCXStr = clang_getFileName(cxFile);
fileStringName = clang_getCString(fileCXStr);
// Compare fileStringName with every cxFile.fileStringName from a different
TU,
// to find the same CXFile also included in a different TU.

There doesn't seem to be a clang_getUniqueFileId(cxFile) function returning
a unique file Id across TUs.

Thank you!

Hi,

when parsing some C++ code with libclang, is there a way to get a unique
identifier for a template function?

For most cases "clang_getCursorUSR" is exactly doing what I need. However,
when using some common trait tricks a mangled C++ name is no longer unique.
E.g. the code snippet below defines two variants of function "dummy" and both
have the same mangled name (but the trait makes sure that only one of them
can get instantiated).

Any idea how I could get a unique identifies for a cursor when traversing
such code?

Thanks,

Michael

//------snip-----------------------------------------

// some traits
template <bool b, typename T>
struct RestrictTo
{};

template <typename T>
struct RestrictTo<true, T>
{
    typedef T Type;
};

template <typename T1, typename T2>
struct IsSame
{
    static const bool value = false;
};

template <typename T>
struct IsSame<T,T>
{
    static const bool value = true;
};

// variant1
template <typename T>
typename RestrictTo<IsSame<T,int>::value, void>::Type
dummy(const T &)
{
// ...
}

// variant2
template <typename T>
typename RestrictTo<!IsSame<T,int>::value, void>::Type
dummy(const T &)
{
// ...
}

//------snap-----------------------------------------

Is this "mangling" in the sense of the USR mangling? They certainly don't
have the same ABI mangling.

John.

Yes by "mangled C++ name" I mean the name returned by "clang_getCursorUSR".

Maybe I did not get your point. But what are you comparing when you're
saying "They don't have the same ABI mangling"?

Only one version of function "dummy" gets instantiated for a given choice
of the template parameter. So sure, the symbols in the object files are
finally unique, e.g.

  dummy(1); // instantiate variant1 with T=int
  dummy(1.2); // instantiate variant2 with T=double

Also, the USR mangling creates unique names when the template parameter gets
specified.

However, the name created by "clang_getCursorUSR" is the same for both "dummy"
variants if the template parameter is not specified.

Regards,

Michael

Hi,

when parsing some C++ code with libclang, is there a way to get a unique
identifier for a template function?

For most cases "clang_getCursorUSR" is exactly doing what I need. However,
when using some common trait tricks a mangled C++ name is no longer unique.
E.g. the code snippet below defines two variants of function "dummy" and both
have the same mangled name (but the trait makes sure that only one of them
can get instantiated).

Any idea how I could get a unique identifies for a cursor when traversing
such code?

This is a bug in libclang; it should generate different USRs for the two 'dummy' functions. Please file a bug at http://llvm.org/bugs/ !

  - Doug

Alright, thanks!

Michael

The ABI mangling uses the dependent signature of a function template, not
the substituted type. In your case, yes, this is technically unnecessary because
the templates happen to perfectly divide the world, so the template arguments
unambiguously dictate the template used. In general, that is not the case, and
you can easily have two templates with the same name that both pass SFINAE
for a particular set of template arguments and instantiate to having the same
type. For a particular call, they could be disambiguated by using explicit template
arguments, by function template partial ordering, or even by only one of them
being declared in any given translation unit.

What is likely going on for you is just a bug. The USR mangling — which is
totally different from the ABI mangling — should be including the return type
of a function template.

John.