[cfe-dev] MSVC /Za considered harmful

[Chandler Carruth]

(I would encourage folks to at least keep STL on the to-line, or mail him
directly as he may not read cfe-dev as closely as others...)

On Wed, Jun 6, 2012 at 2:40 AM, Dallman, John <john.dallman at siemens.com>wrote:

> > Instead of asking them to get rid of it, why don't you ask them to fix
> it?
> > Having a compiler option that disables nonstandard extensions is
> generally
> > desirable.
>
> Hear, hear. Saying "Fix the warnings at /W4 to get compliance" is all very
> well,
> but keeping them from compiling in the first place works a lot better in a
> large
> programming team with people working on many platforms.


The common problem is that standard library headers shipping with the
compile *should* have access to the extensions. They're "implementation
details" that can be relied upon within the standard library, or any other
part of the toolchain.

FWIW, Clang, GCC, and others handle this with a two-pronged approach:

1) Make a special warning mode that warns (perhaps promoting warnings to
errors) on all extensions.
2) Suppress warnings (even if they might be promoted to errors) when they
come from system headers.

This allows the compiler to warn (or error) on extensions in the user code,
without turning off entire features, some of which may be in use.

Note that this does require the extensions to be correctly attributed to
the system header even when templates macros and other devices are used.
Sometimes this is problematic.


Anyways, this is all a bit off-topic for Clang development. The right
approach is for Clang to not set flags when being built by Visual Studio
that are flaky or problematic. People experimenting or developing on Clang
shouldn't have a degraded experience when first hacking on the code.
Hopefully one of our Windows developers can send a patch my way for the
CMake builds? I'm happy to review it, but I don't have windows to really
test it out on...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120606/1083e259/attachment.html>