C++ Standards Conformance from Microsoft
Since we first shipped Visual Studio 2015 we’ve talked a lot about Microsoft Visual C++ compiler and library (MSVC) conformance improvements in this blog. Our team has been focused on making MSVC the best compiler toolset for your development on Windows, and that starts with fully conforming to the existing C++ Standard. This post will look back on the progress we’ve made in MSVC and look forward to our plans in the next version.
We’re not just implementing the C++ Standard, we’re helping to develop it. The MSVC team is a major contributor to the development of the C++ Standard. In addition to our participation in the standards committee meeting, editors from three major Technical Specifications (Coroutines, Modules, and Ranges) work on the MSVC team. We also maintain an open source fork of the Ranges TS that works on our compiler.
Creating a conforming toolset
In 2015 we started on a project that would fundamentally change how our compiler parses and analyzes code. We call this work “compiler rejuvenation,” a term that’s used in Jim Springfield’s excellent blog post from September 2015. We first shipped the rejuvenation work with VS 2015, but we’re still working on it today. It’s always been important for us to show value in our current compiler, maintain compatibility with existing code, and still prepare for a future where MSVC fully conforms to the standard.
Our compiler conformance progress shows the benefits of both the rejuvenation work and other conformance work. We’ve implemented almost all of the features introduced in the C++11 and C++14 standards. There are always bugs, of course, but only three feature areas remain unimplemented. We don’t yet have two-phase name lookup from C++98, we don’t have a conforming preprocessor, and we still have an incomplete implementation of Expression SFINAE.
This progress reflects a huge investment across the compiler but we’ve made especially big gains in Expression SFINAE as well as work on constexpr and extended constexpr: our implementation now conforms to the C++14 rules about extended constexpr. We very much appreciate our customers’ eagerness to tell us where we still have issues. This was especially true with regards to constexpr, where over 150 of you sent us code samples that showed us constexpr bugs remaining in our compiler. All the code snippets your provided in the survey have been turned into test cases. They are all passing with the VS 2017 compiler.
We’ve also heard from you through Connect, User Voice, Report a Problem in the IDE, e-mail, Twitter @visualc, Facebook at Microsoft Visual Cpp, and many other channels. We’ve consistently fixed between 200 and 300 developer-reported bugs in each update. Thank you for taking the time to help us identify issues!
Fixing conformance bugs in our toolset inevitably requires some changes in your source code. It’s not always easy to migrate all your code to new compiler features all at once. We introduced the standards version switches last year that let you opt-in to using features from the latest draft standard (i.e., C++17). And we’ve created a new conformance mode in the compiler, /permissive-, that lets you opt into a mode that disables Microsoft-specific conformance issues. Lastly, we’ve started to update the __MSC_VER compiler version macro with every compiler toolset update and the __MSC_FULL_VER macro with each build. This lets you test programmatically for exactly what version of the compiler is compiling your code.
Some legacy bugs and non-standard behaviors in our compiler would have unintended runtime implications and incorrect behavior. Fixing those bugs in the default mode of the compiler is necessary in order to move the compiler forward towards conformance. When these changes are introduced, we carefully track all of them and provide before/after code snippets with recommendations and rationales for making the changes.
Sometimes, as with the recent keyword changes made by the standards committee in the Coroutines TS, we can’t control required code changes. But we know that it’s important to minimize any changes you have to make in your code when moving to a newer toolset.
Staying current with new features
We’ve spent a lot of time on conformance issues, but we haven’t just been catching up. We’ve been implementing C++ 17 compiler features as time permits. We’ve shipped a few draft standard features in the compiler and have another dozen queued up to release with the next update of VS 2017. Our goal is to complete implementation of the C++17 standard when the standard is approved by ISO. Our current plan is to finish features by the end of the calendar year 2017.
We’ve also continued to make good progress in implementing library features as the standard develops. You might remember that with VS 2015 Update 2 we were feature complete for C++17 features approved at that point. We expect to have all of the major C++17 library features implemented before the standard is published.
Our first focus is on the remaining standards conformance features missing from MSVC. There are two big features still missing in MSVC: two-phase name lookup from C++98 and the C++ preprocessor from C++11. We also have significant work remaining on Expression SFINAE. We’ve started implementation of two-phase name lookup under the new conformance mode, /permissive-, and will preview two-phase name lookup support in mid-2017. And we have plans to start implementing a preprocessor that conforms to the standard. We’re also looking forward to implementing the remaining C++17 features as well as some notable Technical Specifications such as Concepts.
We maintain a summary of compiler features and standard library features for the MSVC toolset. You can use this list to track our progress as we implement C++17 language and library features.
Beyond conformance, which we consider table stakes for a modern C++ compiler, we are also heavily and continually investing in codegen performance, security, build throughput, diagnostics and analysis so that we can be the best compiler toolset on Windows.
Conformance integration with the VS IDE
We have not only delivered conformance improvements in our compiler toolset, we’ve also made the same conformance changes in the VS C++ IDE. You might remember that we use a (separate compiler, EDG, for IDE productivity features.) We carefully turn on behavior in EDG to match conformance fixes as they are made in our toolset.
For example, here’s the Visual Studio 2017 showing constexpr evaluation when hovering over a variable in the editor:
Reference materials on docs.microsoft.com
You’ll find reference information about the conformance improvements in Visual C++ 2017, our current compiler and library conformance status, and places where our compiler still exhibits nonstandard behavior on docs.microsoft.com.
In closing
As always, we welcome your feedback. Feel free to send any comments through e-mail at visualcpp@microsoft.com, through Twitter @visualc, or Facebook at Microsoft Visual Cpp.
If you encounter other problems with MSVC in VS 2017 please let us know via the Report a Problem option, either from the installer or the Visual Studio IDE itself. Track your feedback on the developer community portal. For suggestions, let us know through UserVoice. Thank you!
Light
Dark
0 comments