By Joe Morris & Jim Springfield (MSFT)
This blog provides answers to the following 2 questions.
- What’s new in C/C++ code analysis for VS2015?
- What’s supported and not supported in C/C++ code analysis for VS2015 CTP6 release?
Before we get started, let’s be on the same page on some terminology.
Code analysis: C/C++ code analysis is also known as /analyze. It is sometimes referred to as “static code analysis” or simply “code analysis”. They all mean the same.
Front-end and back-end compiler: Microsoft’s C/C++ compiler consists of two pieces (a front-end and a back-end). The front-end reads in source code, lexes, parses, does semantic analysis and emits the IL. The back-end reads the IL and performs code generation and optimizations. The use of the term “compiler” when referring to code analysis in the rest of this post pertains only to the front-end.
Now that terminology is out of the way, let’s dig into what has changed in code analysis for VS2015.
What’s new in C/C++ code analysis for VS2015?
Let’s start with what has not changed.
- Code analysis is still available in all editions of Visual Studio just like how it was in VS2013.
- No additional checkers added between VS2013 and VS2015.
What’s changed, are 2 key items:
• Front-end rejuvenation: The way we do code analysis under the covers. This is a plumbing change and no impact to the user in terms of workflow.
• Unified error hub: The window, where we present code analysis issues to user. No more separate code analysis window, but instead a unified error hub that is shared by other providers like compile, build, link etc.
This is more of a plumbing change that has no impact to user in terms of workflow. But read on if you want to understand why we did the plumbing change.
Our native code analysis tools do use some of the same code as the compiler. In fact, it is built out of the same source tree, although there are thousands of #if preprocessor blocks to accomplish this. The code analysis tools build an abstract syntax tree (AST) for an entire function by capturing pieces as the regular compiler does its parsing. However, this captured AST is fundamentally different from what the real compiler uses for its data structures, which often leads to inconsistencies.
Also, as new language features are added, most have to be implemented twice: once for the compiler and again for code analysis. This resulted in 2 different code paths and binaries (c1xx.dll and c1xxast.dll), one for code generation and for code analysis.
This was a major pain point for us and a little over a year ago we embarked on a project to finally perform a major overhaul of our compiler codebase. We desired to have one code path for ASTs for both code generation and code analysis. So, we got rid of c1xxast.dll.
With this plumbing change, /analyze under the cover now works as follows…when /analyze is passed to the compiler we use the same DLL (c1.dll or c1xx.dll) that we use for normal compilation and we build the same internal data structures. There is some additional information we keep around longer under /analyze but the overall structure is now identical. Previously, we would start emitting IL (intermediate language) for the compiler backend as we parse a function body, but we now capture an entire function body internally before emitting IL.
This allows us to use the same tree for analysis, code generation, and for implementing new compiler features such as return type deduction and “constexpr”, which requires the ability to inspect an entire function and evaluate it at compile time. With this unification, we expect our code analysis capabilities to get even better.
Unified error hub
In VS2013, code analysis window was a separate window from the error list window. Non-analysis related errors/warnings were directed into the error list window and analysis errors/warnings were directed into the code analysis window.
With VS2015, we are getting rid of the code analysis window and now direct all code analysis errors/warnings into the error list as shown in screen shot below.
We made sure that all the feature functionality that existed in the code analysis window is also available in the new error list window, namely the following…
- Sorting of issues
- Categorization of issues
- Details of issue
- Suppression of issue
- Copy of issue and paste in email
That summarizes the 2 key changes we did for code analysis in VS2015. However, when you use CTP6, please be aware that we have not fully completed the work involved with front-end rejuvenation.
What’s supported in C/C++ code analysis for VS2015 CTP6 release?
Until now, /analyze was disabled in VS2015 CTPs for both C and C++ code analysis. With CTP6 release, we have enabled /analyze for C code.
Supported in CTP6:
- C analysis with most code analysis checks
What’s not supported in C++ code analysis for VS2015 CTP6 release?
Analysis for C++ code is still disabled and we are working towards enabling it in the coming releases.
Not supported in CTP6:
- C++ code analysis
- C and C++ concurrency checks
- Additional driver checks using WDK tools
Our feature crew is focused on finishing up the not-supported functionality as soon as possible. Stay tuned!
PS: This blog does not address anything about managed code analysis. If you want to know, what the deal is for that, please refer to talks and blogs written for that as listed below.
Managed code analysis talks/blogs
- Improve Your Code Quality Using Live Code Analyzers – https://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/714
- Use Roslyn to Write a Live Code Analyzer for Your API – https://msdn.microsoft.com/en-us/magazine/dn879356.aspx