[patch] Don't compute a "patched" storage class

[Rafael Espíndola]

> @@ -766,14 +763,7 @@ public:
>    StorageClass getStorageClass() const {
>      return (StorageClass) VarDeclBits.SClass;
>    }
>
> Can you add a comment on getStorageClass() (both of them) noting that this is the storage class as written in the source code, pointing to getLinkage()?

Done.

> This API change is probably release-note-worthy, because we're going from a semantic description to a syntactic one.

Done.

> +bool CXXMethodDecl::isStatic() const {
> +  const CXXMethodDecl *MD = this;
> +  for (;;) {
> +    const CXXMethodDecl *C = MD->getCanonicalDecl();
> +    if (C != MD) {
> +      MD = C;
> +      continue;
> +    }
> +
> +    FunctionTemplateSpecializationInfo *Info = MD->getTemplateSpecializationInfo();
> +    if (!Info)
> +      break;
> +    MD = cast<CXXMethodDecl>(Info->getTemplate()->getTemplatedDecl());
> +  }
>
> Also look through member specialization info?

I am not sure. The only case where getPreviousDecl is not attached is

struct B {
  template <class T> static void funcT1();
};
template <class T>
void B::funcT1() {}
void test() {
  B::funcT1<int>();
}

Should getPreviousDecl in this example reach the static decl? If so,
we should probably go the other way: remove the
getTemplateSpecializationInfon check and fix the linking.

New patch attached. I will probably commit it tomorrow and fix
isStatic in a followup patch.

> Otherwise, this LGTM!
>
>         - Doug

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: application/octet-stream
Size: 99071 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130403/6679b2a7/attachment.obj>