[cfe-dev] MSVC /Za considered harmful
benny.kra at googlemail.com
Wed Jun 6 03:18:33 PDT 2012
On 06.06.2012, at 09:05, Stephan T. Lavavej wrote:
> 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).
The /Za flag was added to the build of clang not to encourage writing portable code but because an extension was breaking perfectly valid c++ code for "pre-C++11 move emulation". (See the lengthy comment in include/clang/Sema/Ownership.h ). This was with msvc8 though and it's possible that the code isn't used in a way that breaks without /Za anymore or the compiler was fixed in the meantime.
I find the decision to deprecate /Za worrisome because it is a useful feature, but that's your choice and we should remove uses from clang if possible. We don't want to break users who build clang with msvc with confusing error messages if it's easily avoidable. Coverage of building clang with msvc11 will probably decline sharply when it hits the market as setting up a build will require buying a license, build breakages will stay unnoticed for a longer time.
A few words to /W4: We experimented with having an automated builder using /W4 in the msvc8-days but it was very noisy and slowed down the build by 2x or so, which was unacceptable for a bot. This may have changed now but it still requires someone to clean up all the false positives before it will be useful.
> Stephan T. Lavavej
> Visual C++ Libraries Developer
> 0. http://msdn.microsoft.com/en-us/library/0k0w269d.aspx
> 1. http://connect.microsoft.com/VisualStudio/feedback/details/745614/system-error-error-c2382-when-compiling-with-za-disable-language-extensions
> 2. http://connect.microsoft.com/VisualStudio/feedback/details/745643/error-c2382-on-std-generic-category-std-iostream-category-std-system-category
> 3. http://connect.microsoft.com/VisualStudio/feedback/details/745967/compiler-error-c2382-with-standard-header-file-system-error-in-visual-c-2012-rc
> 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.
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
More information about the cfe-dev