CLion 1.1 EAP starts with massive overhaul of the parser, LLDB integration and new formatter options

Posted on by Anastasia Kazakova

Hi everyone,

Summertime and the livin’ is easy, as the song goes. But not for us, as we’re working to bring you CLion 1.1 and announcing the start of the Early Access Program! CLion 1.1 EAP build 141.1935 is already available for download. As usual, it doesn’t require an active license, and you can have both the latest CLion 1.0.4 and CLion 1.1 EAP installed on your machine.

Summer is a hot season, but the hot features we have inside CLion could give it a run for its money. Let’s check them out!

Big parser improvements

You probably know that C++ is a very complicated language to parse. There are so many interesting cases where the overall context can influence the way your code is parsed. Since April we’ve completed a massive overhaul of our parser to make it more accurate and precise. Let me show you a few samples.

Sometimes a function declaration looks very similar to a constructor declaration, but the IDE needs to distinguish them to provide appropriate highlighting, code analysis and refactorings for your code base. Starting with 1.1 EAP, CLion can correctly handle many contexts like the one below:

Another similar example is casting a value to some type vs. declaration of a variable:

Our latest work also affects the parsing of template arguments (CPP-3802, CPP-3758, a fix for the variadic templates CPP-3754), and various typecasting cases like the one below:

These enhancements, introduced deep in the parser, allow us to fix many false positives with incompatible pointer types (CPP-3610, CPP-3612), as well as some initializer warnings (CPP-3613, CPP-3511).

Many other related fixes and improvements are available. If you’ve come across red code or false positives in your code base, give CLion 1.1 EAP a try and share your feedback with us!

LLDB integration on OS X

One of CLion’s key advantages over a plain text editor is the debugging experience. While you can always run a stand-alone debugger separately, debugging inside an IDE saves you time and provides various additional functionality.

Since its very first build, CLion integrates with the GDB backend on all platforms, providing all the essentials in its UI. However, OS X users feel more comfortable with the LLDB. So we’ve improved CLion to provide a more natural experience for that use case as well:

We’ve bundled version 3.6 into the OS X distribution package, making it the default debugger on OS X. If you use CLion 1.0 on Mac and you install this EAP build, your debugger will be switched to the LLDB for the first time. After that you can either stay with LLDB or come back to GDB manually; your settings will be stored in CLion.

Formatter accuracy

CLion keeps your code well formatted as you type. Alternatively, you can apply formatting rules explicitly with the Reformat Code action. You can also configure the coding style guidelines in Editor | Code Style settings and have CLion make sure you stay compliant with them. To help you reflect your desired guidelines more precisely, CLion 1.1 EAP introduces a set of improvements and new options for configuration.

Most of the improvements have to do with the preprocessor directives and conditionally non-compiled code. CLion 1.1 EAP brings a number of new settings for directives (#define, #if/#endif) indentation to Editor | Code Style | C/C++:

  • In Tabs and Indents | Preprocessor directive indent, the default value is 0, and the relative indent is applied to the nested directives:
  • Follow code indent, placed below, is responsible for keeping the indent of the directives the same as for the surrounding lines (off by default).
  • In Wrapping and Braces, Keep when formatting group, there is a new option, Directive at first column. It is set to yes by default, and is responsible for keeping the directive in the first column (if it’s already there) in any situations, regardless of other options.

When you start typing ‘#’, CLion will now automatically align this new directive to the correct position. The closing ‘#’ directive (or ‘else’) is aligned after you press Enter:

The guard block is an exception for the preprocessor directives’ relative alignment and is handled automatically. The code that is conditionally uncompiled is now formatted correctly, following the configured Code Style settings.

Non-existent declarations no longer break template formatting (CPP-3411). And multiline comments are now handled correctly during auto indentation.

Completion for missing keywords

We’ve also implemented missing completion for a few keywords, including:

  • final
  • override
  • alignas after struct
  • noexcept
  • friend

C and C++ files extensions

Since this build you can configure the preferred C/C++ source/header files extensions and use these combinations while creating a new C++ class, C/C++ source or header file. To add/update file extensions go to Editor | Code Style | C/C++ | New File Extensions settings:
These file extensions are available when creating a new C++ class, C/C++ source or header file:

Custom JDK update

In CLion 1.1 we’ve introduced a custom build of JDK 1.8 with fixes from the JetBrains team. It was very warm welcomed, however had some critical performance problems. This build addresses these issues, as well as a problem with high CPU usage. CLion 1.1 EAP build including updated custom JDK is located on confluence page.

The full list of fixed issues can be found in our tracker.

This is just the beginning for CLion 1.1 as we’ve got more interesting features coming soon! Check out this EAP build, follow the updates and report any problems found to our tracker. Your feedback is always extremely welcome!

Develop with pleasure,
The CLion Team!

Comments below can no longer be edited.

32 Responses to CLion 1.1 EAP starts with massive overhaul of the parser, LLDB integration and new formatter options

  1. Chris Krycho says:

    July 9, 2015

    Splendid! Out of curiosity, do you guys plan to release this functionality as an IDEA plugin anytime during the 1.x cycle, or is that probably going to wait till 2.x?

    • Anastasia Kazakova says:

      July 9, 2015

      Looks like it’s going to wait. We still have a lot to do with higher prio.

  2. Anonymous says:

    July 9, 2015

    Is this going to be ported to Resharper C++?

    • Anastasia Kazakova says:

      July 9, 2015

      What exactly do you want to be ported? ReSharper C++ is a separate product, based on another platform. So for sure we share ideas and plans and have technical discussions for both teams, but the code base is different.

  3. Axel says:

    July 9, 2015

    These are awesome news, thought today about how long ago the last update was. And now LLDB support which seems after a first glimpse very good.

    • Anastasia Kazakova says:

      July 9, 2015


  4. Toby says:

    July 9, 2015

    I love JetBrains products and like many others would absolutely love to use this for embedded development. Remote debugging + cross compilation please!

  5. Petter says:

    July 9, 2015

    Have you used CLion successfully with real-world code bases like, e.g., LLVM? The problem with 1.0 was not only parsing, but lack of understanding core C++ concepts such as RAII. Have these issues been addressed as well?

    • Anastasia Kazakova says:

      July 10, 2015

      LLVM code looks mostly correct in CLion (there could be some issues like, not fixed yet). If you meet some problems, please, submit them to the tracker.

  6. Michal Fizek says:

    July 10, 2015

    i have a question. Is clang-indexer still in play, or is it discarded? I think, it takes huge amount of effort to write own indexer and it will probably never support full c++14(not even talking about next c++ versions) It’s already a year in development and it still doesn’t support basic c++14 features. Shall we wait for clang indexer, or it will never be used?

    Thank you and have a nice day.

    • Anastasia Kazakova says:

      July 10, 2015

      CLion relies on it’s own parser, not clang. We are going to implement clang annotator (, but not to use clang for parsing. Due to many reasons we prefer our own solution now.
      To track the activity on C++14 support, follow this ticket, please:

      • John says:

        July 11, 2015

        That is a bit of a curious decision to make. C and C++ are a bit different than most of the other languages that jetbrains has created ides for. Includes are almost quite literally just text substitutions, different from something like C# or Java in that what the meaning and behavior of headers can be modified based on different instances on where it is included. I have had quite a bit of problem with the parser and a lot of the errors have been reported and gone unfixed for a rather long time. If clang was used instead (a tried and tested parser/compiler) i feel the IDE would have been in a more complete state, instead of the potential years it’ll take for the new parser to be up to par.

        Would be interesting to hear some of those many reasons if they can be disclosed.

        • Anastasia Kazakova says:

          July 13, 2015

          First to say, this still can be an option that we consider. We haven’t say final ‘no’ in any way. But today we have two our own implementations in two products (CLion (and the same in AppCode) and ReSharper C++) and ready to try to go with them.
          Talking about reason, there are a couple of them. First is historical – when this exactly parser was started in AppCode, no clang was available in some stable state for the IDE usage and to keep to clang release cycle at that time was a big hard. Second, is more about IDE, in our tools we work with the non-full language model, that means that even when the code can not be compiled/parsed correctly (because of some user’s error), we still try to reformat, analyse and refactor in some correct way, where we can. To solve this we need our own solution. The third one, now clang is moving towards the IDE usage but we still need some control over caching and other options, that it doesn’t provide to us. And this is crucial for performance of the editor. And the last one, is language injections that we need/want to support, when for example a string in C++ can be parsed as it’s an SQL request, not just as string.
          With all that reasons in a pocket we’ve started with implementing our own solution using all the expertise we’ve collected during these years. We’ll see how it goes. Maybe clang will be joined somehow, maybe not. But we’ll do our best to improve the IDE user experience, that’s for sure.

          • Fredrik Sy says:

            July 17, 2015

            Thanks for the detailed reply 🙂

          • KB says:

            August 1, 2015

            I suspect that Jetbrains wrote their own C++ parser because Jebrains’ engineers like to writing parsers, so it’s the default choice.

            However, I have a codebase with a few medium size dependencies, and the performance of CLion is close to unusable–300% CPU usage when idle. Improving Clang’s parser might be the most reasonable path to both increased performance and correctness. It will only get harder to move parsers over time—for example, look at Jetbrains’ use of Java Swing.

            • Anastasia Kazakova says:

              August 2, 2015

              If you could provide a CPU snapshot for us (, please, do it. This can really help to investigate and fix the problem you are experiencing.

              Talking about parser, there are some things around libclang that forces us as an IDE developers to make our own parser. For the IDE to perform efficiently during refactorings and other operations, we needed symbol caching. It’s not only about refactorings, but about all context-aware features in the IDE. Clang does a good job caching while working with individual files, parsing incrementally. But if we talk about the whole project, it starts parsing every file, just like a true compiler should do. And that’s where it can become problematic from inside the IDE.

      • KB says:

        July 13, 2015

        That’s too bad: CLion’s parser is far inferior to libclang’s. This is a fundamental product design flaw; you’re going spend too much time and money fixing issues in your own parser rather than improving the product in other ways. Your custom C++ parser is of no use to anything outside of CLion itself, so it doesn’t need to exist. It can be replaced with libclang.

        • KB says:

          July 13, 2015

          As an additional datapoint: Xcode uses libclang, and it has excellent performance and deals with unparsable code reasonably well.

          • Alexander Kirillin says:

            July 14, 2015

            Unfortunately Xcode provides poor code editing/refactoring support. Clang is a perfect tool, but when it’s used as a 3rd party tool, there’s not much you can get from it – the list of compiler error/warnings and some primitive quick fixes. That’s why JetBrains did it’s own parser.

  7. NoName says:

    July 10, 2015

    I’m still hoping for an IntelliJ UE plugin, to have one IDE to rule them (Java, Python, C/C++) all 🙂 (Next big thing would be Rust-Support =))

    • Anastasia Kazakova says:

      July 10, 2015

      We plan to have it, but not too soon. Quite a lot of tasks with higher priority are in the list.

      • Viktor Kuzmin says:

        July 14, 2015

        Is there any plans to add Android NDK support to Clion soon ?

        • Anastasia Kazakova says:

          July 14, 2015

          Now no. You can use Android Studio. C/C++ support there is based on CLion and can be used for Android NDK development.

  8. Per Larsen says:

    July 18, 2015

    CLion 1.1 sounds like a great update over 1.0. I’m wondering if there are any (even long term) plans to consider other build systems than Cmake? I’d love to use CLion on a codebase that is currently using scons.

    Thanks for making a great product!

    • Anastasia Kazakova says:

      July 20, 2015

      Sure, there are such plans. You can see quite a long list in the subtasks (, including Scons. Follow to get the updates.
      However, this is not the top priority for now, we still have many other things that go first.

  9. Benjamin Mayr says:

    July 29, 2015

    Hello folks, hello Clion-team!

    Clion is a great product and I’m pretty it’ll be soon one of the best C/C++ IDEs on the market. Here at my company we bought two licenses and work on a daily base with it. The IDE is smart and runs super fast. The only thing we are waiting for is LLDB-support for LINUX! If you already support it for OSX (which we also use) it would be a lot easier for us to compile our code under those two operating systems.

    Do you plan full LLVM (with LLDB) support for Linux?
    Keep up the great work!

    • Anastasia Kazakova says:

      July 30, 2015

      Thank you for the feedback. We appreciate it greatly.
      Yes, we have such plans for the future: Feel free to vote and/or comment. Follow to get the updates.

  10. Anindya Chatterjee says:

    July 30, 2015

    I want to test Clang with CLion in ubuntu. I have downloaded llvm, clang (3.6.2) binary from llvm website. I want to use that installation in Clion, don’t want to install Clang with apt-get.

    Here is my system setup:
    Ubuntu – 14.04
    gcc – 4.8.4
    llvm clang – 3.6.2 (portable)
    CLion – 1.0.4

    So how to set it up?

    • Anastasia Kazakova says:

      July 30, 2015

      To provide CMake compiler paths, go to Settings | Build, Execution, Deployment | CMake and pass as CMake options:
      In case CMake fails to find some path to clang libs, etc. you can also set there environment variables:
      Please, share if it helps.

      • Anindya Chatterjee says:

        August 5, 2015

        Thanks. CMake option works.

        • Anastasia Kazakova says:

          August 6, 2015

          Glad to hear. You are welcome.


Subscribe for updates