CLion 2017.2 RC: C++ type casts in quick-fixes

Hi,

CLion 2017.2 release is coming closer and today we are glad to announce Release Candidate build (172.3317.14).

C++ cast operators

CLion is able to indicate situations when user is missing a type cast. As a quick-fix (Alt+Enter), CLion suggested a C style cast previously. Now CLion suggests C++ type casts: static_cast, dynamic_cast, reinterpret_cast, const_cast:

cast_operators

If there is no single valid C++ style cast operator, the C style cast will be used. And if you want CLion to permanently use C style cast operators, simply switch off the setting in Settings/Preferences | Editor | Code Style | C/C++ | Code Generation | C++:

cpp_cast_operations

Besides, a couple of false positives code analysis checks were fixed: CPP-989 and CPP-3111.

You are welcome to download and try the RC build (no license is required). If you find any bug at all, please, report to our issue tracker.


Download CLion 2017.2 Release Candidate

Release notes are available by the link.

Your CLion Team

JetBrains
The Drive to Develop

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

9 Responses to CLion 2017.2 RC: C++ type casts in quick-fixes

  1. Sebastian says:

    Great to see that we are nearing a release.

    I am already excited to read about the Roadmap for the 2017.3 release.

    • Sebastian says:

      Btw. what happended to CPP-8893? Looks like its not going to make it into 2017.2?

      • Anastasia Kazakova says:

        Yes, it’s still under development and requires wider testing. Thus will come with 2017.3 EAP. BTW are you expecting some specific part there? You see there are a several parts which could be implemented independently, so which use case are you interested in?

        • Sebastian says:

          I would like to be able to quickly switch between tool chains and pass tool chain specific options to CMake.
          Such as which generator to use.

          Another thing is to enable specific CMake options for a particular Configuration. For example on MSVC I might want to set -DENABLE_FOO=ON, while on MingW I would not need it.

          • Anastasia Kazakova says:

            These are different issues: toolchains per project (under dev) and different CMake generators (only Makefiles and NMake for the MSVC case are now supported). The latest is not yet in dev.

            Various CMake options for various Configurations should be possible when we finish current feature in dev. Should be available with 2017.3 EAP

  2. Roman says:

    uint32_t *data = data_ptr;

    Clion > “Error: incompatible pointer types, quick fix?”
    Me > “Ok, Alt-Enter”
    Clion > “Do not use reinterpret cast ” :)

    Probably Clion should automatically add “// NOLINT” In this case?

    • Anastasia Kazakova says:

      CLion fixes the compilation error with the quick-fix. However, Clang-Tidy has a warning in this case. We could consider some workaround for such situation, however not yet clear which one. Should the user check the possible error pointed by Clang-Tidy? Or should CLion do smth automatically? No clear answer for us now, but thanks for bringing the problem to the table. We’ll consider.

      • Ivan says:

        Adding a // NOLINT makes sense in this case — it’s fairly absurd that CLion marks the code it suggests to generate with a lint warning (even if it’s done via clang-tidy) .

        • Anastasia Kazakova says:

          Without a cast the code couldn’t be compiled, so CLion makes the code compile correctly. Clang-Tidy check is a bit another story – it shows that potentially this might be an issue and user might want to change it. So we are not sure placing NOLINT by default here is a good solution. We’ll consider some better option for the future, however not sure what it should be.

Leave a Reply

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