Hi clang wizards,
Apparently, when clang is built with MSVC, it uses the /Za compiler option (see ). I say "apparently" because we've received numerous reports (see ), including from people who are building clang (see  and ), that VC11 RC's <system_error> doesn't compile under /Za for boring reasons. We've fixed <system_error> for VC11 RTM, but I wanted to mention this because:
/Za is buggy. Please don't use it.
In particular, it breaks perfectly conformant code like vector<unique_ptr<T>> (reason: ). As a result, we stopped testing the STL under /Za back during VC10's development. That's how thinkos like the <system_error> thing are able to sneak in. We're willing to fix such thinkos as they're brought to our attention (missing this-> is another example, of several), but that doesn't magically fix /Za. (I've asked the compiler team to deprecate /Za and eventually remove it - but while they agree that it shouldn't be used, we have tests that depend on it, and getting rid of it would be a fair amount of work.)
I understand why you'd want to use /Za - because VC has various extensions that you don't want to use in portable code (most notoriously, the Evil Extension of permitting modifiable lvalue references to bind to rvalues). Requesting extra conformance is a good idea in theory. It's just that /Za is flaky, and it's rarely used which means that even less code exercises it. Instead of "request extra conformance", think of it as "enable obscure compiler bugs". Instead of /Za, the best thing to do is to compile at /W4 (which warns about most of the extensions), and also regularly build with another compiler (which I suspect will not be a problem).
Stephan T. Lavavej
Visual C++ Libraries Developer
4. /Za performs an "elided copy constructor" accessibility check that's required by the Standard, but which VC ordinarily doesn't bother to do. However, /Za performs it too aggressively, including during move construction when no copy constructors are being called, even theoretically.