Vote for the VC++ Improvements That Matter

VS 2013 is almost done and VS 2014 is being planned and I’ve been pushing for the VC++ features/bug-fixes that matter most to me. I’ve come up with two requests that seem plausible and valuable. If you like them then you can increase the odds of the VC++ team doing them by voting on connect.microsoft.com (links below).

I think that /analyze is pretty great. It finds lots of bugs in our code. It also misses a lot of bugs, and gives false positives, but I’m going to ignore that for now because code analysis is never perfect and vague requests for greater perfection are not particularly useful.

Instead, I’m going to focus on what I think is a significant deficiency in /analyze that can be corrected relatively easily.

This deficiency is that /analyze is a massive switch that turns on warnings that are reliable and fast, but it also turns on warnings that are unreliable and slow. This coupling of reliable-and-fast with unreliable-and-slow is annoying. Because of the false positives and the long (multi-hour) compile times we only use /analyze on our build machines. These build machines run a few times a day, they churn away for hours, and then they send a report on the new code defects which they have found.

(for details on our use of /analyze see Two Years of Static Analysis)

Roughly 90% of the warnings reported by our /analyze builders are format-string mismatches (incorrect use of printf style functions) and variable shadowing (reusing a variable name in a nested scope). Format-string mismatches are always bugs, and variable shadowing is always confusing and is often a bug. Both of these problems can be detected with 100% reliability and with no significant slowdown of compilation, but with our current setup a developer who triggers one of these warnings will not find out about it until many hours later – often the next day. If VC++ could detect these as part of the regular build then these problems would be found prior to check-in, and 90% of our /analyze build breaks would go away.

One reason that I know that variable shadowing and format-string mismatches can be detected reliably and quickly is because both gcc and clang do this detection as part of their regular compile. It is an area where gcc and clang are clearly superior, and it explains why developers who work primarily on Linux and OSX tend to not check in code with errors of these types.

If you think that this would be valuable and a good use of the VC++ team’s time then please vote for these issues. You have to sign in to vote. You can also comment on the issues. Here are the links:

Format-string error detection should be part of the regular compile: https://connect.microsoft.com/VisualStudio/feedback/details/799869/detection-of-format-string-errors-should-be-part-of-the-regular-c-compile-instead-of-analyze

Variable shadowing detection should be part of the regular compiler: https://connect.microsoft.com/VisualStudio/feedback/details/799873/detection-of-variable-shadowing-should-be-part-of-the-regular-c-compile-instead-of-analyze

There may be other warnings which also fall into the category of fast-and-reliable. For instance, precedence warnings on code such as “a + b ? x : y” are probably fast-and-reliable. I hope that the VC++ team considers moving those into the regular compile, but I honestly don’t care nearly as much because they are much rarer.

It might be best to put the warnings under a /analyze related switch, such as /analyze:fast-and-reliable so that developers can choose whether or not to opt-in to these warnings. On the other hand, doing so will mean that many developers never see the warnings, so maybe this switch should default to on.

Anyway, vote away, and think about what issues you would like the VC++ team to work on for VS 2014.

Other issues

There was some discussion on twitter about whether other issues, such as improved linker performance, should be on this list. I would love to have faster linking – and faster code generation, and faster generated code, and a pony – but such suggestions aren’t necessarily practical and useful. I prefer suggestions that either include a concrete suggestion about what should be done (such as improving the performance of debug code by avoiding specific patterns), or perhaps comparing link performance to other tool-chains such as gcc and clang.

On the other hand, requests for faster linking are worthwhile if they tell Microsoft what developers value so that Microsoft can focus their energies appropriately. If linker performance is a problem for you, create a link repro and then file a connect issue that references your link repro. This makes your problem specific and actionable, instead of vague wishing.

Update, April 2, 2014

Microsoft updated the variable shadowing bug to say “A fix for this issue has been checked into the compiler sources. The fix should show up in the next major release of Visual C++.”

Most excellent.