[LLVMdev] Clang fails to compile template with dependendent Non type template parameter.

KARTHIKVENKATESH BHAT kv.bhat at samsung.com
Tue Oct 23 01:33:05 PDT 2012


Hi All,
I'm trying to compile the following code on clang-

template <int dim> class X {};
template <class T> struct Y {
  static const unsigned int dim = 1 ;
  template <class U> X<Y<T>::dim> f();
};

template <class T> template <class U>
X<Y<T>::dim> Y<T>::f() { return X<dim>(); }

int main()
{
  Y<int>().f<int>();
}

the compilation fails with the following error-
error: out-of-line definition of 'f' does not match any declaration in 'Y<T>' X<Y<T>::dim> Y<T>::f() { return X<dim>(); }

Upon debugging I found that while parsing declaration " template <class U> X<Y<T>::dim> f();"
qualtype of expression Y<T>::dim is treated as "const unsigned int" .
But during definition of Non type parameter Y<T>::dim is treated as a dependent type and hence RebuildTypeInCurrentInstantiation
is called but Y<T>::dim is still not resolved to "const unsigned int" after call to RebuildTypeInCurrentInstantiation.

I'm a bit new to parser code of clang. My doubt were-
1) Ideally shouldn't RebuildTypeInCurrentInstantiation resolve qualtype of expression Y<T>::dim to "const unsigned int"?
2) Non type template parameters are represented as const Expressions in llvm.Everytime we come across Y<T>::dim a new Expression pointer is created which is used to represent the Arg of X<Y<T>::dim> . Since every time Y<T>::dim is a new Expression pointer 
Arg for template X<Y<T>::dim> represnts a diffenent typeOrValue each time.As a result for the same expression X<Y<T>::dim> we create a new type node in getCanonicalTemplateSpecializationType resulting in type mismatch. Wanted to know if this current approach to create a new expression pointer every time the same expression is revisited again is correct?

A similar issue was fixed in gcc at http://gcc.gnu.org/viewcvs?view=revision&revision=156865 .

Would like to get some inputs from community how should i proceed to solve this issue. Thanks!




More information about the llvm-dev mailing list