[cfe-dev] Using clang to parse C++ on Windows

[Reid Kleckner]

On Wed, Oct 30, 2013 at 4:45 AM, Jesper Eskilson <jesper.eskilson at iar.com>wrote:

> On 10/29/2013 10:06 PM, Richard Smith wrote:
>
>> On Tue, Oct 29, 2013 at 7:37 AM, Jesper Eskilson
>> <Jesper.Eskilson at iar.com <mailto:Jesper.Eskilson at iar.**com<Jesper.Eskilson at iar.com>>>
>> wrote:
>>
>>
>>     Hi,
>>
>>     I've gotten stuck on a weird error message from Clang. I'm writing a
>>     Clang-based tool to analyze legacy C++ source code. The code relies
>>     heavily on Windows-specific headers files (MFC, etc) and I have
>>     never been able to get Clang to properly parse MS own header files.
>>     Running the tool on Linux works fine; I've created a set of dummy
>>     replacement header files which are complete enough to allow Clang to
>>     build a usable AST for me. However, running the tool on Windows
>>     turns out to be more difficult than I thought.
>>
>>     I've tried several approaches as to what header files should be
>>     used. Clang was never able to get through the MS header files
>>     without crashing or producing various errors. Since the tool worked
>>     fine on Linux, I imagined that it should be possible to use Linux
>>     header files instead. This got me pretty far, but now I've gotten
>>     stuck on an error which I cannot make sense of.
>>
>>      $ clang -fno-ms-extensions -D_GNU_SOURCE -c foo.cpp -isystem
>>>     ./linux-glibc/include -isystem ./linux-glibc/include/c++/4
>>>     .7 -isystem ./linux-glibc/include/c++/4.7/**bits -isystem
>>>     linux-glibc/include/c++/4.7/**x86_64-linux-gnu
>>>     In file included from foo.cpp:1:
>>>     In file included from ./linux-glibc/include/c++/4.7\**vector:63:
>>>     In file included from
>>>     ./linux-glibc/include/c++/4.7\**bits/stl_construct.h:63:
>>>     In file included from
>>>     ./linux-glibc/include/c++/4.7\**ext/alloc_traits.h:35:
>>>     ./linux-glibc/include/c++/4.7\**bits/alloc_traits.h:56:35: error:
>>>     in-class initializer for static data member is not a
>>>           constant expression
>>>           static const bool __value = _S_chk<_Alloc, _Tp>(nullptr);
>>>                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>
>>
>> At a guess, clang is implicitly running in -fdelayed-template-parsing
>> mode, and this is failing because _S_chk<...> is a constexpr function
>> template specialization that has not been parsed yet. That's a bug that
>> was fixed recently.
>>
>> What target triple is clang using? IIRC we only turn on
>> -fdelayed-template-parsing in MSVC-compatibility mode, but it looks like
>> you're going for something more like a mingw target. (libstdc++ probably
>> won't work in MSVC-compatibility mode.)
>>
>>
> i686-pc-win32. Also, I'm specifying -fdelayed-template-parsing explicitly
> in order to get some of the legacy C++ sources through the parser.
>
> I managed to get around this by brutally removing the initialization in
> alloc_traits.h. Since I have my own copy of the header files, this is ok
> for me at the moment. At some point, however, it would be nice if clang
> could just use Microsofts own header files.
>

What's broken currently?  I'm aware of some known broken things like
atlwin.h, but the STL headers should parse.

You'd probably need the full set of flags that clang-cl passes down to
clang -cc1, which includes things like -fms-extensions -fms-compatibility
-fdelayed-template-parsing -cxx-abi microsoft.  I don't *think* the C++ ABI
matters for parsing, but I'd have to double check.  There are many other
fun flags that can help too, like -fno-rtti, -fno-exceptions,
-D_HAS_EXCEPTIONS=0, and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131030/c40914b1/attachment.html>