<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 14, 2009, at 8:40 PM, John Thompson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>
<div>Doug,</div>
<div> </div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">_Complex is currently a keyword in every mode. We could make it only be a keyword in C99 or GNU mode, then make sure that neither of these modes is turned on by default when Clang is built with VC++. That probably makes sense, since VC++ doesn't support C99 or many GNU extensions anyway.<br>
<br>We can always force tests into specific modes (turning off Microsoft extensions, turning on GNU extensions or C99, whatever), rather than trying to work around problems that are unlikely to show up in code that compiles with VC++. </blockquote>
</div>
<div> </div>
<div>How would you collectively force the tests?</div></blockquote><div><br></div><div>I don't think we can collectively force the tests; we could explicitly add -fno-extensions to the ones that matter.</div><br><blockquote type="cite"><div>I'm kinda feeling that since we're down to just 21 failing tests, and _Complex isn't a problem with VC 9.0, we could probably punt on it for now, and see how it goes with the rest of the tests. But let me know if you want me to persue this.</div></blockquote><div><br></div><div>Let's punt on it for now, then.</div><br><blockquote type="cite"><div> </div>
<div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">What is the actual issue with the redefinition of wchar_t? Are they creating a typedef of wchar_t in their headers? Does the VC++ compiler implicitly define _WCHAR_T_DEFINED?<br>
</blockquote>
<div> </div>
<div>This occurs in a few headers:</div>
<div> </div>
<div>#ifndef _WCHAR_T_DEFINED<br>typedef unsigned short wchar_t;<br>#define _WCHAR_T_DEFINED<br>#endif<br></div></div>
<div> </div>
<div class="gmail_quote">The enclosed wchar_t_fix2.patch seems to fix both the wchar_t issue, and another one I ran into with VC++ headers. I was side-tracked a bit with errors on wchar_t I didn't understand, until I realized that wchar_t was only a C++ keyword.</div>
</blockquote><div><br></div><div>The wchar_t bits look good. Please go ahead and commit!</div><div><br></div><blockquote type="cite">
<div class="gmail_quote">I also ran into some new errors with the VC 9.0 headers on some #pragma's. Defining _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES avoids them, though it's a bit of a hack.</div></blockquote><div><br></div><div>At the very least, please put a FIXME near that define, since we don't want to keep it for long.</div><br><blockquote type="cite"><div class="gmail_quote"> This symbol prevents the definition of some macros, some of which have errors, for example on __pragma statements like this:</div>
<div class="gmail_quote"> </div>
<div class="gmail_quote">__pragma(warning(push))</div>
<div class="gmail_quote"> </div>
<div class="gmail_quote">This is a Microsoft extension not currently supported, right? It seems kind of useful for macros.</div>
</blockquote><div><br></div><div>Right. There are two issues here, I guess. The first is that we don't handle __pragma, although it looks like it's similar "enough" to C99's _Pragma that it wouldn't be hard to implement this Microsoft extension. Second, we have the ability to push/pop diagnostic contexts (see the PragmaDiagnosticHandler in lib/Lex/Pragma.cpp) but, IIRC, not with that syntax. Again, it's probably simple to implement, or we could live with the hack for a bit longer.</div><div><br></div><blockquote type="cite">
<div class="gmail_quote">You mentioned that the Targets.cpp was probably not the right place for the defines, so I moved them to InitPreprocessor.cpp. Is this the right place?</div></blockquote><div><br></div>Yep!</div><div><br><blockquote type="cite">
<div class="gmail_quote">Also, could someone look at the enclosed patch for stdint.h? This also fixes some failing tests, since VC++ doesn't have stdint.h. Who is point on this?</div></blockquote><div><br></div><div>I'm not thrilled about using _M_IX86 and _M_X64 to detect what is really a library issue. I guess in the worst case we could have a configure-time check that determines whether we can #include_next <stdint.h>, but that's.... horrible.</div><div><br></div><div>Unless someone has a better idea... ?</div><br><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></body></html>