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.

About brucedawson

I'm a programmer, working for Google, focusing on optimization and reliability. Nothing's more fun than making code run 10x faster. Unless it's eliminating large numbers of bugs. I also unicycle. And play (ice) hockey. And juggle.
This entry was posted in Code analysis, Programming, Visual Studio and tagged , . Bookmark the permalink.

10 Responses to Vote for the VC++ Improvements That Matter

  1. jrrr says:

    These are highly reasonable suggestions. Voted.

    In the meantime, surely a developer who triggers one of these warnings will find out a little earlier when they break the clang build, right? =]

    • brucedawson says:

      gcc and clang do sometimes let us catch these warnings earlier, but not always. Some projects we only build on Windows, so gcc/clang don’t help. Similarly, some code paths are Windows only. Also, many projects are not marked as warning-as-errors on gcc/clang and therefore new warnings on the builders are often not noticed by developers. We are gradually improving this (building more code on Linux/OSX and building with warnings-as-errors after cleaning up all warnings) but it takes a while.

      And of course even the faster turnaround of the gcc/clang build machines is not as good as a warning that triggers as you write the code.

      Thanks for the vote.

      • brucedawson says:

        Oh yes — another reason not to depend on gcc/clang is that they have, as far as I can tell, no way to annotate wide-character print functions. VC++ can trivially analyze these — gcc/clang need to catch up in this area. If I’m wrong then please tell me how to do this in clang/gcc — my attempts at using _attribute__ (( format( __wprintf__, fmtargnumber, firstvarargnumber ))) have failed.

  2. Paul says:

    Bruce, how do you automate your code analysis runs? Is there a command line that allows specification of custom rule sets? We too have 4-5 hours compiles with /analyze so have to run on a build machine. Right now, we’re resorting to post processing to remove output that is too noisy.

    • brucedawson says:

      We generate .vcxproj files from project description files and we have a conditional macro system that lets us alter what is generated. If our normal VPC command line is:

      vpc +everything /tf /mksln tf2.sln

      Then the /analyze build machine would do something like:

      vpc +everything /tf /define:analyze /mksln tf2_analyze.sln

      The lines unlocked by /define:analyze turn on /analyze, disable linking, and suppress the warnings that we don’t care about. I’ve never actually used the rule sets. I imagine that property sheets could also be used to get this sort of change in build behavior.

      I also do a lot of parsing of the output, mostly to look for new warnings — that’s crucial with aggressive static analysis since getting to zero warnings is usually not possible.

      See the Two Years of Static Analysis post for more details.

  3. Alen Ladavac says:

    Is it worth it? I committed dozens of bug reports to them, a lot of which were pretty obvious and harmful. Those were usually regressions like “debugger doesn’t step into destructor when step into is pressed on a like with operator delete”, “namespace handling in debugger watches doesn’t automatically include the namespace of the current function”, various keyboard shortcuts that were removed between two versions and never restored… All of those things worked in an older version of VisualStudio, but became broken. Some of those got quite a few votes on the old system for bug reports (before the connect site was used), but for all of the the only response was “won’t fix”. I’m not kidding. Not “cannot reproduce”, not “leaving for later version”, just “we don’t care about this.” Heh.

    Honestly, I am much more in need of things like the debugger namespace handling than I am of analyze features. If they cannot fix basic things that are expected from a debugger (and used to work!), I don’t feel like “connecting” with the VisualStudio team until that’s fixed.🙂

    • brucedawson says:

      I don’t know if it is worth it. I’ve definitely had some bad experiences with connect (including a bug that was closed as a duplicate without saying what it was a duplicate of) but I figured it was worth a try.

  4. Pingback: Debugging Optimized Code–New in Visual Studio 2012 | Random ASCII

  5. Pingback: How to Report a VC++ Code-Gen Bug | Random ASCII

  6. Pingback: Debugging Optimized Code–New in Visual Studio 2012 | Random ASCII

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s