<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>
<div><br>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>

<div><br> </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>

<div class="gmail_quote"> </div>
<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.  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>
<div class="gmail_quote"> </div>
<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>
<div class="gmail_quote"> </div>
<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>
<div class="gmail_quote"> </div>
<div class="gmail_quote">I can check in the patches you approve.</div>
<div class="gmail_quote"> </div>
<div class="gmail_quote">-John</div>
<div class="gmail_quote"> </div>