Let’s move on! CLion 2017.3 roadmap


CLion 2017.2 was released just a week ago, but we hope you already gave new version a try and shared your feedback with us. If not, get your free 30-day trial on our site now.

Before moving on to CLion 2017.3 and sharing the roadmap, we’d like to thank our EAP users.

Special thanks

To follow a good tradition, we have selected the most active EAP users with the most valuable contribution and rewarded them with a free personal 1-year subscription for CLion (to extend their current subscription or to get a new one). So let us thank:

  • Ivan Smirnov (YouTrack handle: aldanor)
  • Victor Sergienko (YouTrack handle: singalen)
  • Mario Charest (YouTrack handle: mcharest)

Each of you will receive a personal email with details on how to claim your license. (If for some reason you do not get any email from us within a week, ping us here in the comments.)

CLion 2017.3 and more

And now let’s move to CLion 2017.3!

Note: The following is a preliminary plan; we cannot guarantee that all of the features listed below will be included in CLion 2017.3.

Several interesting features are currently under investigation. The analysis stage doesn’t guarantee that anything functional will make it into the actual release, however your feedback, use cases and comments are extremely valuable. Feel free to share them!

  • Under investigation:
    • Integration with Valgrind (CPP-548)
    • Remote development support (since the topic in general is too broad, we’ll try to focus on some particular improvements, however it’s only a general investigation going on now without any clear decision)
  • Language support:
    CLion 2017.2 got many fixes in various areas of C++ language support. Now we’ve decided to change the strategy a bit. We analyzed issues with the language support on the whole and identified levels, where there is room for improvement. We plan to start from the bottom and work our way up to the top, implementing big overhauls in the problematic areas. This might take more than one release cycle even for one area, but you can expect many issues to be resolved with each finished cycle.

    Besides this, we plan to cover the following:

    • The work on the set of issues with the JUCE code will be continued (for example, OC-8211).
    • Code generation should respect templates (for example, generate definitions).
  • Multiple toolchains support (CPP-10116)
  • Debugger:
    • UI for providing custom pretty printers / .gdbinit for the project.
    • Check and bundle, if possible, GDB 8.0 and LLDB 5.0.
  • Unit tests
    • Gutter icons for unit tests (OC-12323).
    • Fixes and improvements for Google Test and Catch.
  • Continue with performance improvements.

That’s it! Any new feature request? You are always welcome to send them to us over our tracker!

Your CLion Team

The Drive to Develop

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

130 Responses to Let’s move on! CLion 2017.3 roadmap

  1. Pascal says:

    When are we going to be able to use different project models?

    • Anastasia Kazakova says:

      Currently, CLion is tightened with CMake, so adding even one more project model is not an easy task. We plan to start with Makefiles or some general json describing the project. Each option has a few technical difficulties we need to overcome and so for now we are discussing options mostly. But we hope to get something in product maybe next year.

    • Roman says:

      Feels like never :)
      Probably JB plan is to promote CMake until other build systems will die. And it actually sounds reasonable, even Microsoft now recognized CMake. If CMake will have like 70% of C++ market share, then supporting other tools will be pointless.

      • Anastasia Kazakova says:

        Good plan 😉 But there will be always Linux kernel and other projects that will never move to CMake (however, even Boost announced it will!). Besides, there are growing possibilities like Bazel, SCons, and others. So we have to add more options at the end of the day.

        • Pavel Kral says:

          After 2 years we had to migrate from SCons to CMake due CLion (yes it was the reason, because CLion was/is far the best C/C++ IDE on the market, no doubts), but its mediocracy syntax, properties based on directory or whatever context make us scream at least once per month, and we have to once and again remember to SCons/Python flexibility.

          Hey JetBrains, please define API for project model, open it and let community to create buildsystem providers and something like SConsolidator for CLion,

          • Anastasia Kazakova says:

            We would like to share the API, but currently there is no such thing. Everything it dependant on CMake and this will change only with the introduction of another build system. We are currently trying to delegate some resources to this critical task and put more attention to it. Stay tuned!

    • Michael lojkovic says:

      I really just need make support. That way I can uninstall codelite for linux kernel hacking. I have come up with a solution that kind of works for Linux driver development; but, if I’m remembering correctly, code completion didn’t always work. I’m not sure how well a cmake wrapper would work for Linux kernel development.

      • Nehal says:

        The approach I use to spelunk the linux kernel via clion is:

        * create a compile_commands.json for the kernel using an intercepted build
        * use a ruby script to convert compile_commands.json into an clion friendly CMakeLists.txt

        This allows for both code navigation and also a reasonable editing experience.

        See for more details https://github.com/habemus-papadum/kernel-grok

    • Ilya Grozov says:

      Maybe you will find this article useful, but it’s in Russian.

  2. Roman says:

    Valgrind is obviously the most interesting and controversial. Do you plan to eventually implement full-featured analysis GUI?

    • Anastasia Kazakova says:

      We haven’t decided anything in particular here yet. For now we are looking at various options, other tools/integrations, etc. What’s your vision here? What do you expect from the Valgrind integration into CLion?

      • Roman says:

        My employer provides me with Intel Parallel Studio license ( a package that integrates all Intel dynamic analysis tools), so I don’t use Valgrind.

        But I imagine IDE integration with Valgrind should provide something similar to Intel tools, but for less money.

        • Anastasia Kazakova says:

          The only real sample I used on my one was in QtCreator. The integration there is quite nice, but also simple. It allows to filter by leak types and I guess navigate to code.

          As it’s not that big deal to run Valgrind from CLion, we should think more about deeper integration in the IDE, and here we are looking for proper samples for now.

          • Roman says:

            In my experience two most common dynamic analyzes are:
            1. Bounds checking. Here you don’t need Valgrind at all, -fsanitize=address works just well. “Navigate to source” works in Clion out-of-the box if you have llvm-symbolizer in PATH

            2. Performance profiling. Here we got tools like gprof and callgrind/cachegrind. Unfortunately I have never used them, since I have VTune.
            But this is a good area for deep IDE integration: visualizing CPU utilization, hotspot call-tree, annotating functions with runtime info, navigation.

          • Anastasia Kazakova says:

            Thanks Roman!

            For now we were mostly considering Valgrind as a tool to catch memory leaks. Sanitizers case is thus a good option as well here.

          • Jakub says:

            I’ve used all – Valgrind, Helgrind, Cachegrind, and Massif and I quite like the tools. The first three are integrated into QtCreator and, even though it’s simple, it’s much more convenient than having to work with separate programs.

            Having the tools nicely integrated into the IDE always makes my live easier.

          • Anastasia Kazakova says:

            Thanks for reply!

      • mbalabin says:

        In my opinion, GUI support for valgrind’s profiling tools would be very handy. I mean callgrind for cpu profiling, massif for memory profiling and cachegrind for cache profiling (the list is ordered according to my own idea of usefulness). For all these tools you need to navigate through source and call stacks to see hotspots and places of heaviest memory allocation. Preferably not with function-level, but with source line-level precision. For memory profiling, memory consumption vs. time plots also look neat.

        Also, support for some sampling profiler would be useful in case you want to examine an IO bound program (there is a separate ticket CPP-4704).

  3. Giles cope says:

    CLion is by far the best Rust IDE!

  4. John says:

    I really like the clang-tidy integration, but I feel like by default fewer lints should be on. I think this is especially the case for new people trying out CLion and being bombarded with a lot of warnings (some which are arguably false positives). I worry that the current default will lead many to simply turning off the clang-tidy lint all together (and this is coming from someone who’s uses clang-tidy a lot in CI builds).

    One example, in a C++11 project I got warnings that I should be using make_unique, which is a C++14 feature. I obviously can’t fix that warning in this code base. When I open the default clang-tidy configuration in CLion, it’s got an enormous amount of text so it would be non-trivial to find and turn this off. I then need to repeat.

    I think that being conservative and turning on the most important and universal lints by default (like the clang-analyzer- lints that find important bugs) will help ease people into clang-tidy better.

    • Anastasia Kazakova says:

      Thanks you for this valuable comment. We’ll definitely consider changing the defaults. Hopefully more users will share their vision with us and we could come up with some reasonable set.

    • gubbins says:

      Yes, I 100% agree with this. In my team this was exactly the experience – many warnings enabled by default are not useful for us and are adding noise, masking the inspections we care about. The result was, as John feared, that we turned it off (for now).

      Also, it is much too hard to control individual checks. From the warning in the editor you don’t know the name, or even category, of the clang-tidy inspection! I end up googling the text to find the name. It would be much more valuable if there was an option to “Disable this clang-tidy check”.

      Even then it’s a little awkward to add it to the text box in the settings. Better still if they could be configured in a list with check boxes (surely clang-tidy is able to list all known checks?)

      • Anastasia Kazakova says:

        Which checks do you suggest to enable?

        • gubbins says:

          Currently my set is clang-analyzer-*,bugprone-*,readability-*,-readability-named-parameter if that helps. However, I think the ability to immediately disable an inspection is more valuable than getting a better default set.

        • John says:

          I think having a deeper nested UI tree for the clang-tidy inspection that builds the underlying clang-tidy check strings could also help.

          [] clang-analyzer-
          [] core
          [] divide-by-zero

          Which would help users find and enable/disable individual options.

          I assume that CLion can detect a C++98 vs. C++11 vs C++14 project (since it has to do it’s own code comprehension. The moderize- lints that require a certain minimum C++ version, need to be off if the project is using an older version than that.

          A couple others that may be better to be off by default. -cppcoreguidelines-pro-type-reinterpret-cast. There’s a lot of C/C++ that, for better or worse, use this.

          -modernize-use-auto might be better off as well as there are a lot of C/C++ projects that don’t use type inference everywhere and might not want to. It’s nice that it’s there to turn on if a team wants, but I don’t think it’s best to have it on by default.

          -readability-else-after-return also feels a little heavy handed to have on by default, especially for really simple functions where this is used.

          In all, I think that being conservative here will help in the long run use this very helpful feature of CLion

  5. Vitaly says:

    I think, it’s also worth considering Valgrind as a profiling tool. There are probably should also be an option to build a project for profiling and some notification for user that he doesn’t really want to profile debug build :) Regarding viewing results, QtCreator built-in viewer is quite good, but KCachegrind is superb (especially graph view). Personally I prefer using KCachegrind.

    • Anastasia Kazakova says:

      Thanks for the comment and many interesting thoughts, we’ll take a look at KCachegrind for sure.

  6. Eric says:

    Any chance of adding “Debug as root” as was announced for 2017.2 but was apparently not added? (CPP-7224, https://youtrack.jetbrains.com/oauth?state=%2Fissue%2FCPP-7224)

    • Anastasia Kazakova says:

      It was considered as part of the plan for 2017.2, but unfortunately, didn’t make it to the release due to the lack of the resources. We’ll see if we are able to get it in 2017.3. Can’t estimate for now.

  7. Eddie Ringle says:

    Honestly I’d rather JetBrains focus on bringing CLion to IDEA Ultimate as a plugin. (https://youtrack.jetbrains.com/issue/CPP-4141) The whole idea of IDEA is to be a platform to build off of, right? That should mean one IDE should be able to support various workloads.

    So far it’s doing a relatively good job; Gogland’s features were extracted into an IDEA plugin pretty early on, Rust support is being worked on as a plugin, Android support began as a plugin (and unfortunately led to the forking of IDEA to Android Studio, but that’s up to Google), etc. All that’s really missing (for me) is a C/C++ plugin.

    • Anastasia Kazakova says:

      To be honest, IntelliJ IDEA was initially started as an IDE for JVM. It has many things on board now, not only JVM. But to add C/C++ we’d like to find a proper use case for such cross-language dev. I’ll share a sample here. We added Python support to CLion, when we got a clear vision that Python scripts are necessary in C and C++ projects.
      One may mention NDK and JNI here, and we agree absolutely. But would be interested to learn if there are other cases for C++ and Java in one tool.

      • Michal says:

        Hello Anastasia, i think there are some cases. I work with microservices. We have few components in C++, some of them in java and python. Having big number of small apps in different languages is more popular with everyday. One common editor would be a great option! Cheers!

  8. gubbins says:

    I am a heavy user of CLion and I like it a lot. Regarding the “toolchains support”, please would you consider https://youtrack.jetbrains.com/issue/CPP-10345 which I just opened? It’s a simple idea to provide CMake “profiles” which are not tied 1:1 with CMake configurations, and it would immediately add a lot of value for me (much more than, for example, valgrind integration). I realise it overlaps a bit with the idea of toolchains but it seems a good general concept that would fit in with that path.

    I actually think CMake should have the same concept (vaguely akin to maven profiles) and am considering implementing something along those lines, but CLion could do this much more easily as a first step.

  9. HGH says:

    Will reworking the C++ support slow down the addition of the remaining C++14/17 syntax? I don’t care that much about the code analysis at first rather less errors should be reported if the syntax is correct and about performance.

    • Anastasia Kazakova says:

      From C++14 it’s only constexpr left, C++17 was started a bit: https://www.jetbrains.com/help/clion/cpp_support.html

      We believe that at this point, it’s more important to make the overhaul in some areas first, and then to continue with the new language features. That’s not about adding more checks to code analysis or showing more errors, but about correctness of the parser/resolve that affects the intellisense in the whole. And may also affect the performance.

      • HGH says:

        So this means the process could take a few years? And until then I should disable intellisense. I tend to trust IntelliSense too much.

        • Anastasia Kazakova says:

          You shouldn’t if it doesn’t bother you with lots of false-positives. Unfortunately, there are some cases where it fails widely, so the overhaul is necessary (and in order to start support for C++17/20 later as well). But at the same time, we have lots of users that are quite happy with CLion’s intellisence and are using CLion in their everyday work.

          We’ll do our best to make parser overhaul as smooth as possible, so that our current users don’t experience any correctness degradation, but only improvements.

          • HGH says:

            I can live without code inspection as I have lived so far as false positives do bother me. Correctness and performance are most important for me. While overhauling the system, please try to make it faster and never slower.

          • Anastasia Kazakova says:

            That’s of course not only about inspections, but code parsing in general, which affects navigation, find usages, refactorings, etc.
            But be sure we run performance tests on CI, so every change is checked to not affect the performance.

  10. +1 for gdb 8.0

    I run CLion on macOS Sierra, and because of SIP gdb 7.x does not run. I can’t use LLDB as I heavily use some pretty printers which are not available in LLDB. So I am forced to use gdb 8.0 on CLion 2017.2 which come with some bugs :-(

    • Anastasia Kazakova says:

      There is a way to make GDB 7 run on Sierra, but then comes another problem that CLion can’t finish the program correctly (some issue with signals processing). So we need more time to investigate such issues on macOS.

  11. Bhaskar says:

    Interesting! you are planning to do major overhaul for better “Language support”. I am trying to use CLion for a project that has lot of templates all around the code. At the moment, my project is marked with lot of false positive inspections errors. I hope this overhaul is focused more towards CPP templates support.

    • Anastasia Kazakova says:

      Is it possible for you to share the project or some samples? So that we could check the exact issues?

  12. Elliot Morrison-Reed says:

    Are there any thoughts towards adding native Windows Clang support? It seems that Clang support is already there, but if you want to use it with Windows you have to do it through Msys2 or Cygwin.

    It was announced today that Chromium builds are using Clang on windows by default (https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/Y3OEIKkdlu0), now seems like perfect timing to add support.

    • Anastasia Kazakova says:

      Now sure, what you mean here. Clang as a compiler is supported currently, you just need to one from MinGW or Cygwin.

      • Elliot Morrison-Reed says:

        The point is that on Windows that provides a pointless barrier to adoption. Cygwin and minGW both attempt to create a GNU/Linux-like system in Windows. I love using bash and all the GNU tools in Linux, but the user-experience of Cygwin, Msys2, and MinGW in Windows are all terrible.

        This, luckily, is not a requirement for using Clang on Windows, there is an easy to install binary directly available on the LLVM homepage (http://releases.llvm.org/4.0.1/LLVM-4.0.1-win64.exe) for Windows as a regular old Windows program.

        I am a happy full Jetbrains Toolbox subscriber and do all my Python, Go, and Web development using your tools. I also want to use CLion, but I won’t do it with the cygwin or mingw. The MSVC support is a step in the right direction, but I feel like supporting LLVM-Clang binary release would be the easiest way for all parties.

        • Anastasia Kazakova says:

          CLion requires not only a compiler, but also make and cmake. If you can make you Cygwin/MinGW’s CMake work with the clang executable you installed separately, no problem, just pass a proper compiler in your CMake scripts and this should work out-of-the-box.

          • Elliot Morrison-Reed says:

            The whole point is to avoid Cygwin and MinGW, CMake is available as a Windows binary so that is actually not a reason either. As far as I understand, CMake is also bundled directly with the CLion itself, which has nothing to do with Cygwin or MinGW.

            As for make, that is the more interesting problem. It seems like nmake support has been added with the experimental MSVC compiler toolchain. This in installed with the MSVC build tools. In a perfect world, it would be nice if nmake was bundled with windows version of CLion just like CMake is, but I could also live with that having that linked from an external MSVC installation.

            Of course, if we use nmake rather than make, we need to use clang-cl.exe which is bundled in the Clang for Windows.

          • Anastasia Kazakova says:

            On Windows we bundled Cygwin CMake. And for MSVC CMake+NMake as generator is used.

  13. Roman says:

    Can we expect significant improvements in performance anytime soon?

    • Anastasia Kazakova says:

      There are some work in this direction in 2017.2 and in general we are always on it. If you can, better point to some exact issues so that we can check.

      • Roman says:

        It would be nice if at some point you can write a blog about how Clion parses the project, what it keeps in cache, when and which actions invalidate cached index, etc.
        Because it is really hard for user to guess about source of issues.

        When working with large projects, Clion performance becomes really unstable. Sometimes it works very fast, sometimes extremely slow. So you can’t rely on it.

        It seem to me that simply opening a file in editor wont trigger Clion to parse included library headers.
        Here is a step of actions I do:
        1) Open a file for editing
        2) Make a coffee
        3) Now I try to invoke method auto-completion on some object: takes about 15 seconds
        4) Quick documentation on other object takes: 1.5 minutes
        5) And the craziest is switch header/source (Navigate related symbol):
        Record time it has taken in my case was 3 minutes! (While building the whole project takes 8 minutes with g++ )
        (It shows “Resolve operation requires more time..”, so you can cancel and switch manually)

        Good news that after those waits it generally starts working fast. But if you close Clion and open again you will have all those freezes again. Same if you start working on some other subsystem in same project.

        So at high level it feels that there are couple of issues:
        1) Clion parser is slower that g++/clang++. So until everything is cached expect huge freezes.
        2) Clion does not saves state when closed.
        3) Clion is too conservative about memory: I have 64 gigs of RAM, but Clion uses 3.5 gigs at most. For comparison make -j8 can take whole 64 gigs. So at least you can always keep ASTs and other internal representations for every translation unit in project in memory. So you will never have to work with raw text again after its loaded from filesystem. (CPU utilization for CLion is good, so probably replacing my 4 core cpu with 8 cores may help a little)

        • Anastasia Kazakova says:

          CLion should index the project once at start and keep the indices for the future work. It uses the lazy parser, but that’s of course saved between restarts, so it should save the state on close. When you experience problems like that, the thing that you can do to help us to investigate and possibly fix the issue, is CPU snapshot.
          Regarding the memory, you can increase the xmx for CLion. CLion uses 2Gb by default or the value set via xmx vm option.

          • Roman says:

            >but that’s of course saved between restarts, so it should save the state on close
            It feels like not. And it is N1 problem.
            Just made an experiment:
            1) Restarted Clion
            2) Waited for indexing.. to complete
            3) Navigate Definition -> 80 seconds freeze.

            I’ve uploaded dumps using https://uploads.services.jetbrains.com/

            CL-172.3317.49_ripopov_01.08.2017_14.56.03.zip (3.8 mb)
            threadDumps-freeze-20170801-145430-CL-172.3317.49-88sec.zip (77 kb)

            So I have two suggestions:
            1) Fully restore state of IDE when opening project. So user does not have to suffer couple of minutes of freezes when changing between projects
            2) When freezing for > 10 seconds draw some pop-up window. Because sometimes after minute of waiting users tend to pkill frozen tool. So some progress bar can be helpful when performing navigation actions.

            > Regarding the memory
            Yes, I’m aware of JVM options.

          • Anastasia Kazakova says:

            Thanks. We’ll check

          • Anastasia Kazakova says:

            This seems like a know performance issue: https://youtrack.jetbrains.com/issue/CPP-8460. Follow to get the updates.

          • Roman says:

            I’ve identified another action that seem to invalidate Clion cache: editing CMakeLists.txt: when I add new file to project I always get freeze hell for all smart actions.

          • Roman says:

            I’ve uploaded a freeze threadDump (navigate after adding new .cpp to CMakeLists.txt) :

            207 seconds!!

          • Anton Makeev says:

            Thanks for the report.
            We are looking for possible solutions, please follow https://youtrack.jetbrains.com/issue/CPP-9460

          • Taw says:

            Roman is right, I also created a horrible bug on this. If you use curl (and many people do), CLion transforms the computer into an 20years old one, it’s very very slow…
            That is because CLion tries to resolve all the macros, which it shouldn’t. Or perhaps make it optional.

            And the developer is just ignores me…

          • Anastasia Kazakova says:

            Sorry, I’m afraid we have so many things going on here, that some questions in YouTrack were left without proper attention. I’ve pinged the developer.

            In general, this issue has some deep roots in the language engine, so can’t be easily hacked. However, as you see we’ve started some big parser overhaul from bottom to top. And hopefully, it will cover such issues as well. Still I can’t promise you any exact estimation.

  14. Fabian says:

    We are trying CLion at the moment in comparison to eclipse CDT and want to decide which tool suits better for our use cases (embedded Linux development, cross-compiling) at the end of the evaluation phase.

    Neither Eclipse nor CLion are perfect IDEs at the moment. However, we wonder if CLion is a main product for jetbrains (with fast bugfixing and constant improvements) or a niche product?

    Some features would be nice for us:

    – Automatic remote start (through ssh?) of the gdbserver on the remote target (is their a solution right now? This seems to be easier in eclipse).

    – It is not clear for us at the moment how Submodules are handled. E.g., We have a CMake project A containing a folder test which has its own CMakeLists.txt. How is it possible to select the CMakeLists.txt of the test forlder to build, deploy and run?

    – Is their support planned for cmocka?

    – The highlighting of the current line in debugging mode (dark theme) is not clear enough for me.

    – Support for different toolchains is possible but tedious at the moment.

    • Anastasia Kazakova says:

      Hi Fabian,

      In JetBrains all our products are equally important, we don’t have niche/major products. CLion has a big team constantly working on improvements, bug fixes and new features, and there is also a big IntelliJ-platform team which contributes to the CLion experience.

      Now, let’s go through your list one by one:
      – Automatic remote start (through ssh?) of the gdbserver – for now it should be done manually, but you can open the terminal in the IDE and ssh to the remote host. Then you need to configure a special Remote Debug configuration in CLion. After that debugger in CLion can automatically connect to the remote host. Automatic launch via ssh is a part of this task: https://youtrack.jetbrains.com/issue/CPP-7050

      – CLion automatically creates run/debug configurations for all CMake targets found in the project. You can then Run/Debug any of these in CLion, or create your own Run/DEbug configurations. Build and deploy are not yet supported in the CLion’s UI. As a workaround, you can add custom scripts as additional steps to Run configurations.

      – we haven’t considered cmocka, feel free to add a corresponding feature request: https://youtrack.jetbrains.com/issues/CPP

      – “highlighting of the current line in debugging mode (dark theme)” We are unaware of any issues with it, could you please share some screenshot?

      – what are other toolchains of interest for you?

      • HGH says:

        “– “highlighting of the current line in debugging mode (dark theme)” We are unaware of any issues with it, could you please share some screenshot?”

        This is really not a issue but rather a matter of a personal taste. Some IDEs make it very clear which is the currently debugged line other’s not so much.
        The best way to solve this “issue” is to study how other IDEs are doing it and just copy it and add different color options to the color themes. I personally hate editing the color themes.

        • Anastasia Kazakova says:

          CLion highlights the current line in debug mode in blue in the Darcula theme, so it seems it’s quite clear which line is it.

        • Taw says:

          You can change the line color very easy, the CLion colors are very easy to changed, I changed like 50% of them.

  15. Konstantin Isakov says:

    > Now we’ve decided to change the strategy a bit. [..] We plan to start from the bottom and work our way up to the top, implementing big overhauls in the problematic areas.

    Very happy to hear that! The foundations one builds upon are critical for holding all the weight of end user features built on top of it. Making it right is of utmost importance to ensure long-term success of the project.

  16. Nestal Wan says:

    Thanks for considering remote development.

    My work environment requires me to development remotely. Without this feature, I won’t be able to use clion for work anymore and I will be forced to stop my subscription.

    • Anastasia Kazakova says:

      Could you please provide more details on what you mean under remote dev? Remote run, build? Where are the sources, where are the libraries used, what is the setup/toolchains/platforms?

      • Nestal Wan says:

        Windows client desktop running clion, and builds remotely in Linux server via ssh. Remote Linux box has the whole toolchains (gcc/cmake) and libraries installed. Target platform is also Linux.

        Basically just all user interactions (e.g. source code editing) are done in local Windows desktop. Building, running and everything else is done in Linux.

        • Anastasia Kazakova says:

          Thanks for these details!

          • Roman says:

            I have similar environment. The workaround that works fine for me is Clion running inside VNC session on remote linux host.

            Actually Windows Laptops + Linux servers is a very common pattern in industry. And in general you will have to use VNC anyway because of some other GUI tools.

          • Anastasia Kazakova says:

            I see, thanks.

  17. The ability to use a remote server for both build + run/debug is a really high priority for me. It would allow our team to have a stack of high performance build servers and relatively lower powered laptops running CLion.

    • Anastasia Kazakova says:

      So the sources are to be located on a remote host? And where the libraries are? Where the project can be build, on remote location or remote and local?

  18. Steve says:

    With all the talk of improving the toolchain support, there doesn’t seem to be any traction for https://youtrack.jetbrains.com/issue/CPP-1563 and helping us occasional embedded guys out.
    If you’ve ever used the execrable MPLabX IDE (Netbeans) you will know why I would be realise the eagerness for a replacement.

    • Anastasia Kazakova says:

      To be honest, we don’t look into it right now, as there are many others with higher priority. I understand your impatience, but unfortunately can’t even provide a proper estimate here. However, this is an interesting task that we really would like to consider for the future product’s roadmaps.

  19. Ivan Naydonov says:

    What about using clang instead of own parser? As I can understand making such decision will benefit in long term support, quick availability of new language features, performance improvement, external contributions, etc. Is there some solid reasons to not use this way? Something like full incompatibility with platform internal AST or license problems?

  20. Stephen says:

    Currently evaluating Clion as CDT replacement for a large bank on make based project with over 20k cpp/hpp files. Currently we have two issues/wishes.

    1) The project is make based and there is no way to switch from make to cmake due to organizational constraints. That the project model is based on CMake is not really an issue, but we really miss the option of triggering external make with parsing and navigation of warnings/error to source. Naively I would assume this is a low hanging fruit. External tools are supported and you must already have features for analyzing gcc output. Just connect both feature and provide some UI around it.

    2) Performance. It actually performs reasonable fast. After loading of file navigation is immediately available. File is immediately editable and so on. What is painfully slow is the syntax highlighting and other ‘decorations’ like icons in the gutter. Further there is hit or miss. Some files are very fast, others very slow and I cannot see any differences in complexity between the files

  21. Kaiser says:

    Are there any plans to move to clang/libtooling for all parsing, rather than improve the mess of Java in use now? That would be ideal. I’d love to have C++17 support before 2025.

  22. Sadeq says:

    What about supporting multiple projects in one window like your other IDEs (pycharm, phpStorm) ?

    • Anastasia Kazakova says:

      Currently, CLion allows one window per one CMake project. But my question here if you need cross-projects find usages search or completion in that case? What’s the goal of putting two projects in one window? Do you expect navigation jump from one to another?

      • Sadeq says:

        Yes, I’m working on a couple of little projects together and it’s bothering me to jump from a window to another

        • Anastasia Kazakova says:

          If you’d like the navigation, search, etc. to work across the projects, then you need to join these projects under one common CMake and open it in CLion.

  23. Martin says:

    Instead of valgrind I would prefer an interface to libFuzzer.
    libFuzzer has a component in LLVM that instruments the generated code and notifies the fuzzer about potential deviations of the code path. This can be used
    to automatically construct input to functions that exercise each code path.

    A CLion interface could allow the user to apply fuzzing to a particular function. Perhaps a GUI wizard could help to optimize the settings.

    This talk gives a nice introduction:

  24. Taw says:

    Great, but when you will you fix SUPER BASIC things that worked in the past and now are not working anymore?
    Like this one: https://youtrack.jetbrains.com/issue/IDEA-178695

    • Anastasia Kazakova says:

      Interesting, do you have a sample project where it can be stably reproduced? I can’t catch this issue at our side here.

      • Taw says:

        It happens all the time, please note that I use the “old window” for searching:
        Because the new one is very ugly. and non intuitive at all. It worked good until now. I also put a gif in that bug to see that it’s very easy reproducible.

  25. Taw says:

    Is there a plan to make syntax highlight cpp code even if no CMake is present? Or perhaps make this optional?
    Because multiple projects is not supported, the other projects (except the main one) is always marked with red.
    I just want to be colored nicely, that’s all. Also useful when having makefile projects, I can compile them in cmdline, but make them syntax highlighted nicely.

    • Anastasia Kazakova says:

      You see, that’s not just about simple highlighting. With C++ even for proper highlighting you need to parse/resolve… So you need to know quite a lot of information about the project, which we now take from CMake.

      But if your question was about if we plan to support other build systems/project models, then – yes, we do. Hopefully, this will be in our roadmap for 2018.

      • Taw says:

        Thank you for the nice reply. I understand your point, please please put yourself in my shoes.

        For example sometimes I read cpp (without any build system in them) files that are not in the project and it always show with red. Sometimes I just read github code, just to understand something or to read better code…
        For example I load and read curl or openssl libraries. Eclipse makes them highlight them ok, Visual Studio does, but CLion shows symbols with red, because of CMake missing.

        CLion tries to do all the things very proper and very smart but it should’t try to do that all the time. Just simple C++ parsing would be enough sometimes, just make it work like Notepad++ to highlight classes/functions/keyword, would be great.

        • Anastasia Kazakova says:

          I understand your request, however “simple C++ parsing” is not that simple most of the time. We still need to get some standard library symbols, parse some includes, etc. So at least some model is crucial here. But we consider making it possible to open project from a directory with sources somehow. Still haven’t decided anything in details about it for now.

  26. Victor Sergienko says:

    Thanks for the gift!

    Wow, I got some weight in the community 😀 May I please attract more attention to my pet bugs then:

    * (probably very easy) https://youtrack.jetbrains.com/issue/CPP-9284, speaking of the gutter – better gutter icons for methods, instead of four-way arrows that can lead to a number of methods, when I specifically need a base class. Adding simple icons to a N+-item dropdown would help.

    * (probably very easy) https://youtrack.jetbrains.com/issue/CPP-10295 – just dumbly not working. https://youtrack.jetbrains.com/issue/CPP-10298 is somewhere related, I believe.

    * (probably quite a bit of work) https://youtrack.jetbrains.com/issue/IDEA-131223 – git by-patch commit mode. I know it’s worked on, but I don’t thing tying to the changelists is the best idea. I would prefer just to pick patch-by-patch when committing, plus save the state of patch selection when cancelling and re-opening commit dialog.

    * (probably hard) https://youtrack.jetbrains.com/issue/CPP-809 or its simpler variants https://youtrack.jetbrains.com/issue/CPP-1370 – “may not fit into the receiver type” warnings are essentially useless, while they could be super-useful.

    • Anastasia Kazakova says:

      Thanks, Victor!

      First two are redirected to the IntelliJ platform, hopefully they can put them to the roadmap. We’ll see.
      The last two are interesting and we’d love to make our Data Flow Analysis more flexible and smart in that sense. We have a few ideas and we’ll see if we can fit them into 2017.3 or 2018.1 release.

  27. Victor Sergienko says:

    Speaking of custom pretty printers / .gdbinit (.lldbinit too, I hope?), can I please remind of per-VARIABLE watch renderers… oh, how come there’s no such feature request? Here’s one: https://youtrack.jetbrains.com/issue/CPP-10688

    Per-type renderers (https://youtrack.jetbrains.com/issue/OC-9817) can be worked around with .lldbinit/.gdbinit, but not per-variable renderers.


    • Anastasia Kazakova says:

      Indeed, look very reasonable. Hopefully, we can think about it when come to tasks like hex view (which I really hope can happen soon, but can’t promise some particular release).

  28. Taw says:

    First of all thank you very much for your answers, Anastasia.:)

    Also, I forgot to remind you about some old and great features, that do not work anymore in the latest versions, I struggle to understand why such great basic features are replaced by “smart” non-intuitive ones.

    Very simple to fix, just increase the size of the edit box. This is a very silly issue, a lot of use use a lot of extensions and that edit box is a way too small…

    Very use little arrow that got the history, now it’s missing…
    Yes, I can use the original dialog(-Dide.find.as.popup=false) , but what will I do (except returning to Eclipse) if the original dialog will be removed in 2018?

    I am very concerned that the dev team, instead of concentrating on trully important things, they change the existing good ones into bad ones…(like the 2 I posted above)


    • Anastasia Kazakova says:

      When we introduced new popup for Find in Path many users shared their positive feedback on it. Of course, it’s not yet ideal and requires more work that will be done definitely. But I can’t say that it’s “introducing bad things”. At least, not true for many IntelliJ-based IDEs’ users.

      I hope we can make it work for you as well, sooner or later. What is your main annoyance with the new popup?

      • Taw says:

        The new pop-up indeed looks good but it misses some basic functionality that existed in the old style. I told in my first post what are the problems.

        File extension mask is too.small. As you can see, there are also some users commented on that bug, saying it’s too small.Perhaps it’s good for users which use only 1-2 extensions, but for the rest of us it’s bad. I use like 5-6 extensions for my file types, I really cannot see anything in that tiny box. As you can see in my pictures attached, only .c and .cpp files fit in that box, other types do not fit…

        Arrow missing for history on file types.

        As told you before, it’s ok for me, I use the old style(please don’t remove it) but now another bug appeared, which you tell me that you cannot reproduce. I can reproduce 100% (tried on 3 computers).

        • Anastasia Kazakova says:

          Regarding the last one, we are currently trying to reproduce it. So on it now. Hope to get some results soon.

      • Taw says:

        Please Anastasia, be honest. You, as a C++ passionate, do you think that this space for the extensions is big enough? (marked with red). At most, 2 extensions fit in that space….why do not increase this space a little more? The “Find in path” field is unnecessary huge, for example.

        So this is not “introducing bad things”? It’s like decreasing your browser title bar and you cannot see the full path…

        • Viktor Sergiienko says:

          May I politely note that a) it has to work on smaller screens too, plus b) I believe, the majority of people will never use more than 2 file extensions, but will be searching for quite a complex strings from time to time.
          File extensions are not the browser’s address bar. Search string is. Come on, be honest :}

          • Taw says:

            Viktor, I work with a lot of extensions, because my project contains:
            – c. and .h files – some 3rd parties in C language
            – .cpp and .hpp – main project in C++
            – .txt and .cmake files – CMake
            – .conf and .cfg files – config
            – .pl and .pm files – Perl tests
            – .py – Python tests
            – .sh – bash tests

            And sometimes I search only strings in some projects, only in sources, only in tests. The main problem is that I cannot see what is the current selection. Is it .c and .h, or .c and .cpp and .hpp and .h? I always have to click on it, press ctr+space, so the edit box is bigger and see all the file masks. And THEN I can properly do the search.

            Instead of see(“oh, the masks are ok”) and search.

        • Anastasia Kazakova says:

          To me personally, it’s ok. But I’m on mac and probably the layout differs. I agree we need to check and if there is a room for improvement, then improve. However in general. I still think with any of these issues new popup is much more convenient than the old-style dialog. But that’s just my personal view, since you’ve asked about it. I agree the issues should be addressed.

      • Taw says:

        Forgive me if I add so many comments (I try not to, believe me :P), but I found another scenario in which the very small edit box for File Mask of the new popup is a bad thing.
        I want to search something in only .c and .cpp files
        – In 2016 I press ctr+H (my shortcut), I see that the File Mask is only .c and .cpp and I search the string.

        – In 2017 I press ctr+H and I cannot see what is the complete list of file masks (because it is too small) and then I have to:
        1. Click on the file mask edit box
        2. Press ctr+space (2 key presses) to drop down the menu(because it does have an arrow, very smart but non intuitive at all) so the box is expanded and I can see the complete list of file masks
        3. Another click to close it.

        So 4 clicks in CLion 2017 compared to 0 clicks in CLion 2016. This is way I tell it’s a bad thing, because un-necessary clicks.

        I soooo love the ide.as.popup=false, hope you keep it in CLion 2018.

        I hope this is my last message and I really appreciate for being so supportive and because you answer all messages. :)

        • Anastasia Kazakova says:

          No worries, we appreciate your feedback. Also it always make sense to understand the use case under the issues better and in more details. So we appreciate your comments.

  29. Helge says:

    Please support debugging of core dumps soon. This is incredibly important for a serious developement tool like CLion.

  30. Taw says:

    Anastasia, is there a chance to implement this in the future?
    I assume that’s not important in your “TODO” list, but it’s worth to ask. :)

  31. Joshua says:

    I have been using VisualStudio for almost 20 years now and I always thought that there is no real alternative out there. I felt sorry for all those command line tool Linux developers left with no real IDE. Now started to evaluate CLion for a hobby project and I am blown away! There is nothing I miss on Windows (except some minor ReSharper features I appreciated for VS but have not yet been implemented for CLion). And due to CMake, I can now even work on Mac and Linux with ease. And even develop and test on a Raspberry Pi! Byebye Visual Studio, I won’t miss you.

  32. Eric says:

    We use a custom build system here for various reasons and are quite happy with it. I am eager to try CLion, however I think we’ll need to wait for support for project models / build systems. I truly hope you are able to get to that in 2018.

    I want to try CLion because we’re unhappy with other IDE choices currently available. We maintain over 300 projects and often have a dozen or more IDE instances open. Most IDE’s we’ve tried launch very slowly (even when launching without a project) or consume vast, undue resources – too much to nimbly jump around many projects.

    I have to admit that CLion being written in Java does concern me on the resources front. I’ve not tried it yet so my concerns may be misplaced. I’m not hating on Java or managed languages at all. We are just embedded/native programmers and have always wanted an IDE that is as resource conscious as we are, and that values responsiveness as much as we do.

Leave a Reply

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