<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 30, 2013 at 4:45 AM, Jesper Eskilson <span dir="ltr"><<a href="mailto:jesper.eskilson@iar.com" target="_blank">jesper.eskilson@iar.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 10/29/2013 10:06 PM, Richard Smith wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Tue, Oct 29, 2013 at 7:37 AM, Jesper Eskilson<br></div><div><div class="h5">
<<a href="mailto:Jesper.Eskilson@iar.com" target="_blank">Jesper.Eskilson@iar.com</a> <mailto:<a href="mailto:Jesper.Eskilson@iar.com" target="_blank">Jesper.Eskilson@iar.<u></u>com</a>>> wrote:<br>
<br>
<br>
Hi,<br>
<br>
I've gotten stuck on a weird error message from Clang. I'm writing a<br>
Clang-based tool to analyze legacy C++ source code. The code relies<br>
heavily on Windows-specific headers files (MFC, etc) and I have<br>
never been able to get Clang to properly parse MS own header files.<br>
Running the tool on Linux works fine; I've created a set of dummy<br>
replacement header files which are complete enough to allow Clang to<br>
build a usable AST for me. However, running the tool on Windows<br>
turns out to be more difficult than I thought.<br>
<br>
I've tried several approaches as to what header files should be<br>
used. Clang was never able to get through the MS header files<br>
without crashing or producing various errors. Since the tool worked<br>
fine on Linux, I imagined that it should be possible to use Linux<br>
header files instead. This got me pretty far, but now I've gotten<br>
stuck on an error which I cannot make sense of.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
$ clang -fno-ms-extensions -D_GNU_SOURCE -c foo.cpp -isystem<br>
./linux-glibc/include -isystem ./linux-glibc/include/c++/4<br>
.7 -isystem ./linux-glibc/include/c++/4.7/<u></u>bits -isystem<br>
linux-glibc/include/c++/4.7/<u></u>x86_64-linux-gnu<br>
In file included from foo.cpp:1:<br>
In file included from ./linux-glibc/include/c++/4.7\<u></u>vector:63:<br>
In file included from<br>
./linux-glibc/include/c++/4.7\<u></u>bits/stl_construct.h:63:<br>
In file included from<br>
./linux-glibc/include/c++/4.7\<u></u>ext/alloc_traits.h:35:<br>
./linux-glibc/include/c++/4.7\<u></u>bits/alloc_traits.h:56:35: error:<br>
in-class initializer for static data member is not a<br>
constant expression<br>
static const bool __value = _S_chk<_Alloc, _Tp>(nullptr);<br>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
</blockquote>
<br>
<br>
At a guess, clang is implicitly running in -fdelayed-template-parsing<br>
mode, and this is failing because _S_chk<...> is a constexpr function<br>
template specialization that has not been parsed yet. That's a bug that<br>
was fixed recently.<br>
<br>
What target triple is clang using? IIRC we only turn on<br>
-fdelayed-template-parsing in MSVC-compatibility mode, but it looks like<br>
you're going for something more like a mingw target. (libstdc++ probably<br>
won't work in MSVC-compatibility mode.)<br>
<br>
</div></div></blockquote>
<br>
i686-pc-win32. Also, I'm specifying -fdelayed-template-parsing explicitly in order to get some of the legacy C++ sources through the parser.<br>
<br>
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.<br>
</blockquote><div><br></div><div>What's broken currently? I'm aware of some known broken things like atlwin.h, but the STL headers should parse.</div><div><br></div><div>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.</div>
</div></div></div>