[cfe-dev] MSVC /Za considered harmful

Stephan T. Lavavej stl at exchange.microsoft.com
Thu Jun 7 10:10:05 PDT 2012


[Michael Spencer]
> As for the /W4 specific extension warnings, I have been unable to find
> exactly which numbers they are. We could specifically add these to our
> build.

Here's the one for the Evil Extension:

C:\Temp>type meow.cpp
struct X { };

void meow(X&) { }

int main() {
    meow(X());
}

C:\Temp>cl /EHsc /nologo /W4 /MTd meow.cpp
meow.cpp
meow.cpp(6) : warning C4239: nonstandard extension used : 'argument' : conversion from 'X' to 'X &'
        A non-const reference may only be bound to an lvalue

I believe there are others, but I can't remember them at the moment.

> And on a related note, are bug reports about non-standard and
> non-extension errors in the Visual C++ Libraries useful? We often
> encounter cases with, for example, missing typenames and incorrect
> name lookup when compiling with Clang.  We have added support for
> emulating MSVC's behavior, but it would be nice to be able to not have
> to do this, as it makes writing portable code harder.

For the STL (and anything that the STL drags in) - yes, I consider such things to be bugs, and I'll gladly accept such reports so I can fix them. (Missing typename/template disambiguation is obvious, so it just needs to be pointed out. Ditto for missing this-> to reach into dependent base classes. For more complicated things like two-stage name lookup, I would appreciate a more detailed explanation of what a conformant compiler will do with the code.)

As you may have heard, VC10+'s Intellisense is powered by EDG. What you probably haven't heard is that there's an undocumented command-line option, /BE , which invokes the EDG front-end (for compilation only, it isn't wired up to codegen). We build all of our STL tests with (and without, obviously) this switch, to ensure that EDG and therefore Intellisense can parse us. This catches various STL bugs (and EDG bugs, more rarely). By default, VC runs the EDG FE in its bug-compatible "I can't believe it's not C1XX mode". However, there's an "even more undocumented" option, /BE /dE--parse_templates , which tells EDG to be aggressive about compiling templates when they're first seen (like all other compilers). This catches lots of missing typename/template disambiguation, plus stuff like straight-up typos, which C1XX doesn't validate when a template is first seen.

In VC11, I've cleaned out most of the problems revealed by /BE /dE--parse_templates in the STL (and also the PPL headers that <future>/etc. drag in now). There was one in <scoped_allocator> that I wasn't able to trivially fix - I'm going to let Dinkumware do that surgery. In the long run, we'll build our STL tests with /BE /dE--parse_templates to continuously run this strict validation (we don't yet because something in our headers is triggering an ICE under these options - it has been reported).

However I'm sure that clang will find additional issues, which I'd love to fix.

For libraries that the STL doesn't drag in, I can't speak for their maintainers, but you can report them through MS Connect.

STL




More information about the cfe-dev mailing list