In the latest Preview release of Visual Studio 2019 version 16.1, we’ve added two quick fixes to the Code Analysis experience focused around uninitialized variable checks. These quick fixes are available via the Quick Actions (lightbulb) menu on relevant lines, accessed by hovering over the line or squiggle, or by pressing Ctrl+Period.
The first release of Visual Studio 2019 brought in-editor code analysis and various C++ productivity improvements, including a quick fix for the NULL to nullptr rule and others. In implementing further code analysis quick fixes, we are basing decisions on the following criteria: 1) the warning should have a low false positive rate; 2) the warning should be high-impact and have a potentially significant downside if not corrected; 3) the warning should have a relatively simple fix. Looking at the most feasible warnings, Preview 3 provides quick fixes for the following:
C6001: using uninitialized memory <variable>
Visual Studio reports warning C6001 when an uninitialized local variable is used before being assigned a value, which can lead to unpredictable results. This warning may be fixed by adding empty curly braces so that the variable/object is value-initialized (will be all zeros).
This warning and corresponding quick fix are enabled by default in the Microsoft Native Minimum ruleset.
C26494: VAR_USE_BEFORE_INIT
This warning goes hand-in-hand with the previous one and is fixed in the same way. However, while warning C6001 is generated where the uninitialized variable is used, warning C26494 shows up where the variable is declared.
Note that this warning and corresponding quick fix are not enabled in the default ruleset, but rather under the C++ Core Check Type Rules. To change rulesets in an MSBuild project, navigate to Property Pages > Code Analysis > General; for projects using CMake, add the "codeAnalysisRuleset" key into your CMakeSettings.json with the value set to the full path or the filename of a ruleset file.
Send us feedback
Thank you to everyone who helps make Visual Studio a better experience for all. Your feedback is critical in ensuring we can deliver the best Code Analysis experience. We’d love for you to download Visual Studio 2019 16.1 Preview 3, give it a try, and let us know how it’s working for you in the comments below or via email. If you encounter problems or have suggestions, please Report A Problem, or let us know via Visual Studio Developer Community. You can also find us on Twitter @VisualC.
This kind of assignment looks absolutely horrible in a legacy codebase, however it fits very well in a mostly uptodate Modern C++ source.As a bare minimum, there should be an option to quickly select between the styles before VS makes the change.
Ideally, I think that VS should check the surrounding code and fix the initializer according to the style found in the current function and/or translation unit. VS should already have similar information by...
Hi Istvan - I totally agree. Which is why I raised this here and as feedback/a bug. Whats worth knowing all is that the code it generates is so "modern C++" centric, that it won't even compile on any compiler earlier than VS 2013 (even just assigning a null pointer or setting an integer to 0 )- which as you say, is a serious pain for legacy code.
Fortunately Microsoft are treating it as a...
Hi Istvan and Mike,
As I replied below, we're looking into this further and will discuss to see if we want to revisit this to make it better. We want users to have a good experience whether working with modern or legacy code; however, do note that these quick fixes, based on the C++ Core Guidelines (to "help people to use modern C++ effectively"), are imeant to help users modernize code, and to make it...
`C26494: VAR_USE_BEFORE_INIT`- this warning looks like it needs a warning itself!
I will also submit this as a formal feedback item, but the auto code fixes it produced when I tried it were very “unnatural”/strange to look at.e.g.int a;
char *pPtr;
becomes
int a{};
char *pPtr{};Rather than the much more natural:
int a = 0;
char *pPtr = nullptr;Do others agree?
Hi Mike,
We’ve implemented the quick fix following the C++ Core Guidelines for modern C++ code – in this case, it refers to the standard “ES.23: Prefer the
{}-initializer syntax.”Let me know if this makes sense or if there’s anything else I can help with. 🙂
You might wish to follow up. I raised it as a feedback item and it’s now being treated as a bug. The code it generates is so “new” that it won’t even compile on VS 2012 and earlier for even the most trivial cases…
Mike,
Sorry for the delayed reply. I agree, following standards without any further discussion or nuance isn't ideal. :) I just sent your feedback here to the feature team, and we'll take a look at revisiting this and discuss how to make it a better experience. If you'd like to send me an email to chat about this further, with me or others on the team, please do reach out at eli.fessler@microsoft.com. Thanks for your...
I have to say Eli, I strongly disagree with the C++ Core guys on this one. Blindly following their recommendations, IMHO, is not a great idea, and in this instance, drastically reduces readability "at a glance".Not only that if this is a shared code base (with source that gets built via multiple compilers - e.g. in my case I use VS 2005, 2013 and 2019 for some of the same source - legacy OS support),...