C++ Analysis and Common Language Runtime (CLR) Options


When compiling C++ code with MSBuild and executing analysis (most often in a solution with a mix of C# and C++ code), you might run into an analysis warning like this:

WARN: Microsoft extension activated by "/clr:nostdlib" compiler option is not supported, skip analysis of files: [F:/Vsts/_work/226/s/MyManagedProject/Interface.cpp]

If you receive this warning on all C++ files in your build, your analysis might even fail with this error. :slightly_frowning_face:

##[error]java.lang.IllegalStateException: The "build-wrapper-dump.json" file was found but 0 C/C++/Objective-C files were analyzed.

Indeed, our C++ analysis does not support /clr (Common Language Runtime Compilation) compiler options, and for some good reasons.

The Microsoft /clr option enables Microsoft language extensions, which does not just affect the artifact compiled, but makes some changes in the C++ language itself:

  • it enables new keywords
  • some new data structures
  • declarators
  • and more

CLR extensions are not supported by our C++ analyzer because it is not standard C++, and our C++ analyzer uses clang to parse C++ files. clang is a standard/open-source language front-end in the C language family, from the broader LLVM project.

So what should you do if you receive this warning or this error?

First, it might be worth checking if your code is really making use of CLR extensions, such that the flag really needs to be enabled during compilation. If not, you can remove the flag(s) and you’re good to go. :+1:

And if that isn’t an option, you have some choices to make.

  • Continue to analyze only compatible C++ files. If not all of your C++ files make use of the /clr option (and you only receive a warning during analysis), you can leave things as is and continue to receive analysis results on the flies on which analysis can be executed.

  • Ignore C++ files during analysis . If all your C++ files use the /clr option legitimately, you can exclude all C++ files from analysis by adding sonar.exclusions=**/*.cpp,**/*.h as an analysis parameter (or adjusting these settings in the Project Administration UI), and make sure to include any other file extensions that are handling C/C++ code.
    Doing that will not provide code analysis for these files but will also not cause your analysis to fail. This would also mean you no longer need to execute the build wrapper.

  • Limit the use of /clr. Usually, the purpose of C++/CLI (the extension enabled by /clr ) is to interface between C++ and C#. Typically this belongs in a very thin interface layer. Maybe this is the trigger for you to look into how you’re using this option, and if it’s due for a refactoring.

I hope you find this useful, and please don’t hesitate to create a new topic on this forum if you need more help.

Kudos to my colleague @Antoine for providing most of the original research on this topic.