Parsing MFC code with clang - some info of coming works

Here is a small update regarding my work to patch clang to make it
capable of parsing MFC code.

I created a MFC project using MSVC 2008 and I clicked on every
possible option to pull as much header files as possible. The result
.exe is a good looking Office-like executable with Ribbon and
everything.
Then I have a small .sln and .vcproj parser where I extract the list
of source files with the proper option necessary for parsing (mostly
include path and define list )

I then call clang on each file and I look at the result.
Right now, there are about a dozen problems preventing clang to parse
the MFC project. Most are small problems that will require minimal
work

But then there are 2 issues that will be more challenging and I plan
to work on them in the coming weeks.

1. Allow to specialize a function within class scope.
Example:
class A {
    template<typename T> _com_ptr_t(T* p)
    {
    }

    template<> _com_ptr_t(char* str)
    {
    }
};

2. Unqualified lookup into dependent bases of class templates
Info here: http://clang.llvm.org/compatibility.html#dep_lookup_bases

This one is causing the majority of compile errors when parsing MFC
code with clang.
I admit trying to implement this one scare me a little..

happy hacking..

But then there are 2 issues that will be more challenging and I plan
to work on them in the coming weeks.

1. Allow to specialize a function within class scope.
Example:
class A {
   template<typename T> _com_ptr_t(T* p)
   {
   }

   template<> _com_ptr_t(char* str)
   {
   }
};

That shouldn't be too hard. AFAIK, this is mostly removing a rather arbitrary restriction.

2. Unqualified lookup into dependent bases of class templates
Info here: http://clang.llvm.org/compatibility.html#dep_lookup_bases

This one is causing the majority of compile errors when parsing MFC
code with clang.
I admit trying to implement this one scare me a little..

I think the strategy is to make delayed template parsing substitute types immediately, so that you never *have* dependent bases. I believe that's what MSVC does, anyway.

Sebastian

I did some investigation today and it is not so simple.
Given: (and this occurs in MSVC headers)

  template<class U>
  struct X1 {
     template<class T> void f(T*);
     template<> void f(int*) { }
  };

This code create a situation when you specialize a member function
template without specializing the class template itself. This is
illegal in standard C++ and clang doesn't support that but MSVC does:
http://stackoverflow.com/questions/3052579/explicit-specialization-in-non-namespace-scope

Just removing the arbitrary restriction assert in DeduceTemplateArguments.
I continue to investigate.