CLion starts 2018.2 EAP: Google Sanitizers, Gradle C++ projects, recompile a single file, and IDE performance improvements

Hi,

Today we have a bit of good news for you! CLion starts the 2018.2 Early Access Program. The first build (182.2371.31) is now available for download.
800x400_blogCL_2018_2_EAP_@2x

While we still continue fixing bugs in v2018.1 and publishing bug-fix updates for this version, we are now ready to start the EAP for v.2018.2, and we are looking forward to listening to your feedback here in the comments and in the tracker. Here are the main highlights of the changes in the first 2018.2 EAP build:

Read more details below and get the build from our site:

Download CLion 2018.2 EAP

Google Sanitizers

For our users to benefit from Dynamic analysis tools, we’ve previously added Valgrind Memcheck support to CLion. Now we are happy to announce Google Sanitizers support! Find the quick FAQ with details below.

How to run my code with sanitizers?

To detect addressability issues, memory leaks, data races, and uninitialized memory issues with Google Sanitizers, you need to manually provide the corresponding build options in your CMake script. For example, for Address Sanitizer you have to provide: -fsanitize=address. The corresponding CMake command will look similar to:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address -O1 -fno-omit-frame-pointer -g")

How is CLion’s integration beneficial to me?

In case you use Clang >= 3.8.0 or GCC >= 5.0.0, when you run/debug your application or unit tests with sanitizers, CLion visualizes the sanitizers output in a “Sanitizer” tab in the run tool window. It allows you to review the list of errors and their traces in the IDE, navigate to sources, preview the sources or inspect the frame information:
sanitizers

Which sanitizers are supported and what are the options for each one?

CLion supports:

  • AddressSanitizer and LeakSanitizer (a list of supported platforms for ASAN is here)
  • ThreadSanitizer (a list of supported platforms for TSAN is here)
  • MemorySanitizer (a list of supported platforms for MSAN is here)
  • UndefinedBehaviorSanitizer (a list of supported platforms for UBSAN is here)

The documentation for all the sanitizers, including all the available settings and supported platforms can also be found on the official Google page. To pass settings to sanitizers in CLion use Settings/Preferences | Build, Execution, Deployment | Dynamic Analysis Tools | Sanitizers page:
sanitizers_settings

Most sanitizers are supported on Linux and macOS, and if you are on Windows, you can try using them via the WSL toolchain.

Recompile a single file

While working on a project and implementing some local changes in a file, you might want to check them as soon as possible, at least to be sure that the compilation still works. To speed up your development cycles, CLion now has a new feature – Recompile, which can be used to rerun the compilation for a selected file (via Shift+Ctrl+F9 on Linux/Windows, ⇧⌘F9 on macOS, or via Run | Recompile menu option), without triggering the recompilation of the whole project.
recompile

How it works

This works for CMake and compilation database projects for now. Under the hood, in the first case, CLion calls the CMake target for the corresponding file, instead of a direct compiler call (which CLion actually never does, as it always delegates the build to CMake). In the simplest case, when current file belongs to the currently selected Run/Debug configuration, the build target from this configuration is used. Otherwise, CLion attempts to find a suitable configuration, prioritizing those with the same CMake profile (build type) as the currently selected one.
For compilation database in order to recompile CLion simply calls the compilation command from the compilation database json file (with some little changes to output options and fsyntax-only).

Known limitations

Currently recompilation doesn’t work for MinGW – the fix in CMake is expected in one of the future CMake releases.

Check our webhelp for more details on how the recompilation in CLion happens.

Gradle C++ projects

Gradle is the first build system to join CLion in addition to CMake (if you don’t count Cargo for Rust projects, available via a plugin or a 3rd party Bazel support)! Note, that CLion currently supports only new Gradle C++ projects, the old style won’t work. Sample projects can be found on GitHub.

To open a Gradle C++ project in CLion, open the build.gradle file from the project sources:
build_gradle_open
Tell CLion to open this file as a project and provide the Gradle settings; you mainly need the Gradle JVM location (you can later change them under Settings/Preferences | Build, Execution, Deployment | Gradle):
gradle_settings
and you are done! Your new Gradle C++ project is up and running in CLion (including the full C++ code insight support):
gradle_project

Known issues and limitations

A few limitations are present now:

  • As we’ve said, only new Gradle C++ projects are supported
  • For now, Create Project wizard can’t create Gradle projects
  • Non-correctly resolved code on Windows with MSVC (CPP-12936)

And other known issues linked to this parent one in our tracker.

Database plugin

Starting with this EAP build, CLion comes with the full database tools support. It’s enabled via Database Tools and SQL plugin by default and the functionality corresponds to the DataGrip IDE:
db_plugin

The plugin allows you to work in CLion with many known Databases (like MySQL, PostgreSQL, Oracle, and others): explore the content of the DB, read and modify data, get code completion, refactoring and other intelligent features for the SQL language, and execute queries – all this without ever leaving the CLion IDE. Read more details about the supported features in our webhelp.

Performance improvements

As we said before, we have a plan to continually improve performance and eliminate UI freezes. Some fixes have already been implemented in v2018.1, others are planned for v2018.2 and v.2018.3.

Indentation calculation on lexer

As a part of this plan, this EAP introduces a lexer-only indentation processor. This means code in your editor in CLion is formatted based on the lexer information. It’s obviously faster, especially for C++, than doing a full code parsing and resolve, but some issues are possible. Thus we kindly ask you to report them to us when detected.

If you experience big issues with the formatter on lexer and would like to switch back to a more accurate solution, please, use the cidr.indent.lexer.only.cpp setting in Registry:

  • In Find Action dialog (Shift+Ctrl+A on Linux/Windows, ⇧⌘A on macOS) type Registry;
  • open Registry, type cidr.indent.lexer.only.cpp to search for the setting and turn it off.

Note, this is still a work in progress.

Fixes for several typical UI freezes

This build comes with fixes for code completion cases (CPP-12036) and freezes related to the Search Everywhere action (CPP-11711).

CMake specific macros for external tools

External tools in CLion are capable of running any external scripts or executables. Configure them in Settings/Preferences | Tools | External Tools and call them independently via Tools | External Tools | or add a step to your Run/Debug configurations:
external_tool_macro

CLion 2018.2 EAP comes with a set of CMake specific macros available for configuring programs, arguments, and the working directory of your external tools:

  • CMakeCurrentBuildDir – Build directory for current CMake run configuration
  • CMakeCurrentBuildTypeName – Build type name for current CMake run configuration
  • CMakeCurrentExecutableName – CMake executable used for current run configuration
  • CMakeCurrentGenerationDir – Generation directory for current CMake run configuration
  • CMakeCurrentProductFile – Product file for current CMake run configuration
  • CMakeCurrentProgramArguments – Program arguments for current CMake run configuration
  • CMakeCurrentTargetName – Target name for current CMake run configuration

Other changes

There are more changes and fixes introduced in CLion 2018.2 that worth mentioning:

  • Valgrind Memcheck results can be exported to XML format-files and imported back when needed
  • CLion 2018.2 EAP supports and bundles CMake 3.11
  • C++ language support improvements:
    • An analysis was added that can prevent returning a local variable from the function and getting crashes on the run time:
      escape_local_scope
    • Several cases of incorrect “value escapes local scope” warning were fixed (CPP-5538, CPP-10621).
    • Incorrect overload resolution of initializer lists when using templated functions were fixed (CPP-11767).
    • Support was added for the GCC extension for templated user-defined string literal (CPP-12689).
  • CLion also got some valuable goodies from IntelliJ platform:

One last thing to mention is the Conan plugin for CLion. It allows you to configure Conan profiles and match CMake and Conan profiles. The work is in progress and your contribution is very welcome!

That’s it! Full release notes are available via the link. If you are interested in what else is planned for v2018.2 find the roadmap in the earlier blog post here. Download and try the build right now and share your feedback with us!

Download CLion 2018.2 EAP

Your CLion Team
JetBrains
The Drive to Develop

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

66 Responses to CLion starts 2018.2 EAP: Google Sanitizers, Gradle C++ projects, recompile a single file, and IDE performance improvements

  1. Paul Belanger says:

    The inclusion of new project models is exciting!

    Are you looking into the abiliity of using Ninja (as opposed to Makefiles) as a CMake generator? For my project it would speed up unchanged rebuilds dramatically.

  2. Victor Sergienko says:

    Like the new flat icons!
    I just think the gray color is inconsistent: half of the icons are colored when enabled, but some, like “Save”, “Open”, “Paste”, “Evaluate expression”, “Edit configurations”, “Revert”, “Settings”, “History” look inherently gray. They could use a drop of color, like in “Show running list”.
    “Smart step into” doesn’t become gray even when disabled.
    // I personally would love “Compare” redone to represent two-pane window, like it used to be.

    Commit and push icons look definitely closer to their meaning.

    • Anastasia Kazakova says:

      Thanks Victor for the feedback. Could you please submit it to the IDEA tracker for developers/designers to consider your comments? And they mind have some questions there probably.

  3. Alex says:

    Hi! Thanks for such good release.

    Unfortunately, I cannot find the Dynamic Analysis Tools item in my preferences. Is there any to do to get it?

    • Anastasia Kazakova says:

      Can you see CLion-EAP | Preferences | Build, Execution, Deployment | Dynamic Analysis Tools?

  4. Thanks for adding the sanitiser tools right to the IDE! It makes them much more convenient to use and thus more accessible.

  5. Tano says:

    The Git icons are changed again, so these are the 3rd package in 2 years…Is there any chance to make them stable and not change them anymore?

    • Anastasia Kazakova says:

      We are updating the icons to follow some platform guidelines and overall good practices. Unfortunately, we can’t predict general guidelines/styles changes, but we prefer to update the visuals to follow them anyway. Hope you like the new IDE look.

  6. Tano says:

    I like the fact that all Git icons in the lower left are white but “Commit” icon is green, meaning that’s enabled, but I have nothing to commit :))))).

    • Anastasia Kazakova says:

      Please share your comments in IDEA tracker, so that our design and UI team can take a look, discuss and maybe update the icons to make them more convenient to you.

  7. Tano says:

    Anastasia, it seems the folder tree is changed, meaning that if I have folder A containing only folder B, they are not shown in a tree, they are shown as one folder named “A/B”.
    How can I change to the old behavior?
    Thanks

  8. Kirill Sapozhnikov says:

    Thanks for EAP, although I would like to see more performance fixes than features like Gradle (I suppose it is implemented for future support for Kotlin/Native)
    Meanwhile, is https://youtrack.jetbrains.com/issue/CPP-13036 bug or feature?

    • Kirill Sapozhnikov says:

      Looks like bug, anyway. Just happened another similar issue with loosing focus from editor
      https://youtrack.jetbrains.com/issue/CPP-13037

    • Anastasia Kazakova says:

      This doesn’t contradict – we have people working on performance improvements. They have a huge plan and we are going to release more fixes in 2018.2. Gradle is implemented by other people in the team responsible for project models support.

      The bug you’ve mentioned is currently under investigation. We need first to reproduce it on our side. Please stay tuned in the ticket.

  9. Adam says:

    This won’t matter for a month, but the EAP doesn’t recognize my license and there doesn’t seem to be an obvious way to add my license key. So it thinks I’m a trial user and will expire in a month.

    • Anastasia Kazakova says:

      EAP build doesn’t require a license. It’s a free build which expires in a month after building. But we usually publish new EAP builds every 1-2 weeks

  10. John says:

    Would love to see Doxygen parameters colored like they are in IntelliJ in 2018.2 :)

    https://youtrack.jetbrains.com/issue/CPP-10311

    • Anastasia Kazakova says:

      That’s indeed a great addition, but currently we can’t allocate free resources to this task.

  11. Tano says:

    Anastasia, is any chance to decouple CMake from projects any way this year?
    I would like to have just a simple feature: resolve correctly symbols, not depending on CMakeLists, which currently works perfectly with Eclipse and Netbeans. In CLion I have a lot of red (unresolved), because of CMake dependencies…thanks

    • Anastasia Kazakova says:

      Decoupling doesn’t mean it will work like you describe. What you request is an open project from sources (which is a next step after decoupling). The closest change in this direction is open project from compilatation database json files, which is gonna come in 2018.2 most likely. As for now, we’ve added Gradle C++ projects support (which means decoupling is nearly there).

      • Tano says:

        My scenario is very basic: I have a main project with a lot of subprojects (mostly external_project in CMake). The problem is that the subprojects’ symbols are not resolved properly, when I open the subprojects I got a lot of red colors.
        Eclipse solves properly, Netbeans also. CLion does not. They don’t care about CMake, they just solves all of things properly.
        Therefore when I have to work on a subprojects’ tasks, I have to use Eclipse.

        I think this happens also when you use multiple projects in a CLion project (example: client + server)

        • Anastasia Kazakova says:

          Why can’t you open the main project in CLion?

          • Tano says:

            I can open the main project, I didn’t say that I could not open it.
            I said that the other “subprojects” (which the main project compiles with externalproject_add command) symbols’ are not resolved.

            But this is a known problem in CLion, if the CMakeLists.txt is not perfectly created to support multiple projects, it won’t work. That’s why I hate the CMake dependencies.

            I would just like to load any project without CMake and all symbols be resolved, like Eclipse does.

          • Anastasia Kazakova says:

            But you still have to describe the dependancies for IDE to resolve the code correctly. So you either use a known build system, some extra information like compilation json database format, or IDE’s specific project model (the last is a very bad case for C++, I guess, as we already have a bunch of them in the C++ family).

          • Tano says:

            You know better than me what it needs to be done, I am just a bit sad that a very old version of Eclipse (I am using Juno) can handle any project I load and a modern IDE like CLion cannot, because I really like CLion.

          • Tano says:

            I downloaded curl (for example), I deleted all Makefiles and CMakeLists from it, openend with Eclipse and I don’t get any red (unresolved symbol), when I press “go to definition”, I can go to any symbol from it.

            How can Eclipse do it? Perhaps it’s magic? :-)

            I think that it just uses the #includes from the source files to resolve the symbols, whithout caring about anything else. Why this cannot be implemented in CLion also? (perhaps could be an option)

          • Anastasia Kazakova says:

            I don’t think Eclipse will get the code correctly when it depends on any build flags, compiler options, etc. However Eclipse has it’s own project model, that it uses for any project you open in it. So it still resolves in the context of this project model.

          • Tano says:

            “I don’t think Eclipse will get the code correctly when it depends on any build flags, compiler options”

            I totally agree, Eclipse does not care, but I think this is a good thing. I don’t see any problems in symbols being resolved all the time, not dependable on CMake or any build system.
            In CLion when I forgot to enable a specific flag in CMakeLists, a lot of my code is red, which is very annoying. The only good reason for this is that CLion detects when unused #includes, very cool indeed.

            I open libressl with CLion, half of the code is red, I try to go to a function definition…it does not work.

            Couldn’t this be implemented in the future also? I don’t know when to expect this, perhaps next year?:)

          • Anastasia Kazakova says:

            > I don’t see any problems in symbols being resolved all the time, not dependable on CMake or any build system.

            But that could be not possible. For example, PCH can’t be resolved correctly w/o analyzing the build options. And other cases.

            We plan to implement the ability to open a project from directory. But similarly to other implementations (like in VS) it will still be required to provide some options/info in some format/UI.

          • Georg says:

            What usually helps for me is to add a few lines to the CMakeLists.txt file generated when importing the project.
            In the example below, I add paths to the Qt include files. After this, the unresolved Qt symbols disappear, and I at least can navigate to the Qt header files – despite the fact that the original project is a rather complex Makefile project.

            Of course, compiling is still not possible using the CLion compile functionality. Navigating compiler errors is also not possible. But navigating source code works nicely.

            Georg


            set(CMAKE_CXX_STANDARD 11)
            # BEGIN manual edit
            include_directories(../3pty/qt/5.10.0/linux64/include)
            include_directories(../3pty/qt/5.10.0/linux64/include/QtCore)
            include_directories(../3pty/qt/5.10.0/linux64/include/QtWidgets)
            include_directories(.)
            # END manual edit
            include_directories(autocomplete)

          • Tano says:

            @Anastasia, I agree that PCH could not be resolved, but not all projects have PCH, we understand this. At least will work for projects without PCH

            @Georg
            Yes, I do this sometimes, but I cannot commit to git with these lines because my colleagues will kill me.:-)
            I have an entire sub-project (50k lines) which is compiled with some hackish things from the main project(through some external things via python and cmake combinations), and this sub-project is entirely red because CLion wants clean and proper CMakeLists.

            This is how my right bar looks like for every file in that project: https://imgur.com/a/s6NllRG

            I go to Eclipse->new project with existing makefile, set the parent folder (which contains my project and sub-project) and everything is resolved perfect…:(
            Don’t get me wrong Anastasia, I just want to uninstall Eclipse :)

          • Anastasia Kazakova says:

            There are different cases, PCH was just a sample. To resolve you need to get at least some project model. Eclipse just assumes a very simple model under-the-hood, which doesn’t enable lots of smart things doable otherwise.

          • Tano says:

            Hmm, it seems that some of them are resolved in multiple files and CLion cannot decide which of them to use, therefore it marks them as red, which is very ugly. I opened CPP-13089, thanks

          • Anastasia Kazakova says:

            Please, follow-up in the comments. We have a few questions there.

          • Tano says:

            “Eclipse just assumes a very simple model under-the-hood, which doesn’t enable lots of smart things doable otherwise.”

            Exactly!!!! Thank you!
            Perhaps some of us are willing to sacrifice the “smart things”, but to resolve the symbols properly sometimes.
            For example I just want to look into a new library from git to check some functions implementations (yesterday I investigated libmagic), it’s impossible to do this with CLion, because it don’t even go to a definition and everything is red.

            A lot of us just read the code and don’t need these “smart things”. A lot of my people (like my colleagues) build in the command line, and they don’t like CLion because it cannot resolve all the symbols, they really don’t need very complicated stuff.

            Perhaps when opening a project you can select “disable smart settings” and just read the code and edit without any smart things enabled.

            Also in this way the guys with different systems (Makefile) could use CLion and compile in cmdline.

          • Anastasia Kazakova says:

            Probably, there is some misunderstanding at this point. CLion (as well as others IntelliJ-based IDEs and other smart tools we do) is here to provide smart experience to developers. We do care a lot about many smart features on board. Thus we need a project model describing the code to resolve it correctly. If you don’t need all of them, you can easily take a text editor or similar.

            Saying this, I’d like to remind you, that you still can open a folder in CLion, as just a folder (or any single file), w/o any project model. This will limit the code insight features, but will do a simple job of reading the code in the simple editor.

  12. michael lojkovic says:

    Any word on how close CLion is to make support? I would love to be able to uninstall CodeLite.

  13. Denis Marinov says:

    I have to say Clion is improving by everyday. Even the compiling, which I found very slow when I posted a couple of weeks ago, is now much faster with mingw-64. Coding in Clion is now extreme accurate with all the intellisense, code completion etc. Though, I’d to know if u plan to redesign the documentation popup for C/C++ too, like currently with Java, JavaScript and TypeScript? I found it more cleaner and readable. So let me know!

  14. YuShaoqi says:

    When the Clion will support touch bar as IDEA 18.2?

  15. Nestal Wan says:

    Is the remote build feature removed from 2018.2? It’s not in this EAP.

  16. NBlizz says:

    I hope “Reformat Code” option to be added in the pop-up menu that open via right-click on the module folder in Project window.

  17. Felipe Zacani de Mello says:

    I really miss the ability to debug in CLion using the visual c++ compiler. Windows 10 is my main dev workstation and the MS compilers are far superior. How far is CLion from that?

    I really love the ide and I noticed the recent performance improvements, thanks for that!

    • Anastasia Kazakova says:

      Thank you for your support.

      Unfortunately, debugger for MSVC is a hard task. The VS debugger is licenses for VS only. So we have to reimplement it from scratch. We are on it, but that’s not a quick fix.

  18. Gideon Yuval says:

    Any chance of shrinking the RAM footprint? I have a big project, and on a 2GB virtual machine Clion (on that project) does not stand a chance.

    • Anastasia Kazakova says:

      You can change it in VM settings (Help | Edit custom VM options). However, 2GB is a minimal recommended size for C++ projects, especially for a big project. Maybe even more than 2GB is required. We work on improving the memory usage, but in general typical C++ project requires quite a lot.

  19. Pranas says:

    Nice I just wondering when It will be possible to do the same as with Ecplise i.e. same environment for Java and C languages (no need to switch between different IDES)?

    Otherwise it’s good direction.

  20. I have like when I have see all mankind full of enthusiasm and somehow satisfied ,but there is a lot of work to be on the top. Congratulations to the whole team of CLion !

  21. Dmitri Shvetsov says:

    Hi Anastasia,

    Could you please clarify what exactly does “only new Gradle C++ projects are supported” mean?

    My issue is that I am using the latest versions of both Gradle (4.9) and CLion (2018.2) on my Ubuntu 17.10 but I get the following message upon loading gradle project into CLIon:

    “The IDE doesn’t support ‘cpp’ gradle plugin. Consider to use new gradle C++ plugins, see details at https://blog.gradle.org/introducing-the-new-cpp-plugins

    Thanks in advance,
    Dmitri.

    • Anastasia Kazakova says:

      Yes, only new Cpp plugins are supported (which are described by the link https://blog.gradle.org/introducing-the-new-cpp-plugins). So the format of the Gradle C++ file is slightly different. Old format is not supported in CLion.

      • Dmitri Shvetsov says:

        I am new to both CLIon and Gradle and I am probably missing something but I don’t quite understand how to check/install “new” c++ plugin fo Gradle. As I mentioned I have installed Gradle (4.9) and CLion (2018.2) but it does not work. What exactly should I do to get a new c++ Gradle plugin?

      • Dmitri Shvetsov says:

        Just in case below is my gradle script. It compiles and works fine when I am executing from command line:

        apply plugin: ‘cpp’

        model {

        components {
        greeter(NativeLibrarySpec) { }

        // Let’s try using the library
        main(NativeExecutableSpec) {
        sources {
        cpp.lib library: “greeter”
        }
        }
        }

        binaries {
        all {
        cppCompiler.args “-g”
        }

        withType(SharedLibraryBinarySpec) {
        if (toolChain in VisualCpp) {
        cppCompiler.define “DLL_EXPORT”
        }
        }
        }
        }

Leave a Reply

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