CLion 2017.3 EAP: MSVC extensions, multiple compilers on one project and more


Please welcome the new EAP build of CLion 2017.3 (173.3188.25). Download the build by the link below. No license is required for this build, and you can install it side by side with your stable CLion version. Give it a try and let us know your feedback here or in the issue tracker.

Download CLion 2017.3 EAP

MSVC extensions

With an experimental support for Microsoft Visual C++ compiler in CLion, we’ve received complaints about incorrect code highlighting and false errors in code analysis in case MSVC extensions are used. That’s why we’ve started the work in this direction and this EAP build brings some important results. CLion now supports:

  • __uuidof, __forceinline, __unaligned, and __alignof keywords
  • Pointer type attributes: __ptr32, __ptr64, __uptr, __sptr
  • MSVC built-in data types: (unsigned) __int8, (unsigned) __int16, (unsigned) __int32, (unsigned) __int64, __wchar_t
  • Additional format specifiers, like %I32 and %I64

Besides, CLion can now treat clang’s -fms-extensions flag correctly.

Switch C/C++ compilers with ease

These changes allow you to conveniently switch compilers on one project. This could be helpful in case you’d prefer to test/debug with various compiler versions, do some extensive testing with several GCC/Clang/MSVC compilers on the same project or just easily configure a compiler for your project in CLion.
Recently we’ve introduced multiple toolchains support in CLion 2017.3 EAP. This made it possible to have several toolchains at once on the same project and switch easily between them. Updated Toolchains page now allows you to select Make, C and C++ compilers:


You can either rely on a compiler/Make detected by CMake or select a custom one. Note, that CMake options -DCMAKE_C_COMPILER and -DCMAKE_CXX_COMPILER take precedence over these compiler settings.

If the compiler is changed, the project will be automatically reloaded to apply the changes (CMakeCache.txt is cleared and CMake is regenerated). By the way, the same happens in case you change the CMake options in Settings/Preferences | Build, Execution, Deployment | CMake.

Other changes

We continue our work on avoiding bogus warnings and errors in the code highlighter and inspections for the C++17 features that are not yet supported in CLion. This build fixes an annoying issue with marking code as unreachable in case constexpr if is used.

That about wraps it up! Full release notes are available by the link.

Here is a quick reminder of the changes we’ve already made to CLion 2017.3 EAP:

Download CLion 2017.3 EAP

Your CLion Team
The Drive to Develop

This entry was posted in Announcement, Early Access Preview and tagged , , , , . Bookmark the permalink.

15 Responses to CLion 2017.3 EAP: MSVC extensions, multiple compilers on one project and more

  1. Olof says:

    Is there a link to the YouTrack item list for this release?

  2. Read Stanton says:

    Is there any way to get CLR extensions like Console::WriteLine() fully working? I managed to get it to work through CMake tricks but CLion still gives me an error.

  3. Signer says:

    Thanks, this update significantly reduced bogus errors on UE4 projects.

  4. Taw says:

    Hi Anastasia, I didn’t know where to put this question, and I ask it here:
    I watched your CPPCON video (, which is great, but I don’t know what keys did you pressed on 26:00 to get that small popup menu in order to transform from std::bind to lambda.
    I get that warning “transform from std::bind to lambda”, but I don’t know how to magically transform the code, like you did in the video :)

    • Anastasia Kazakova says:

      That’s the usual Alt+Enter, that provides quick-fixes in CLion. The warning and the fix is coming from the Clang-Tidy integrated into CLion. And it works the same way our own fixes and checks are working in CLion, so the usual Alt+Enter does the job.

  5. Cam says:

    The ease of specifying the compiler is much better. Is there a way to specify the compiler for certain targets and have it persist in a file that would be checked into version control? I don’t want to have my whole team have to manually specify the configuration for all of our build targets.

    • Anastasia Kazakova says:

      Currently CMake options (that are necessary to assign to the Run/Debug configuration to set compiler to a certain target) are stored in the workspace.xml, which is normally not checked into source control:

      An alternative approach here is to use CMake toolchains file.

      • Cam says:

        Great! I will follow that issue.

        Unfortunately, I have to pass the compiler arg to cmake at configuration time because our embedded target and host target share the same project. So, it’s my understanding the toolchains file wouldn’t help us in this scenario. Would you agree with this?

  6. Stan says:

    Great blog nice one for writing this.

  7. stanley says:

    terrific post thanks for writing this.

Leave a Reply to Anastasia Kazakova Cancel reply

Your email address will not be published. Required fields are marked *