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

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.

CLion_EAP
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:
function

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

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:
cast

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:
lldb_debug

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:
    preprocessor_indent
  • 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:
directive_align

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:
file_extensions
These file extensions are available when creating a new C++ class, C/C++ source or header file:
new_cpp

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!

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

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

  1. Chris Krycho says:

    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?

  2. Anonymous says:

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

    • Anastasia Kazakova says:

      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:

    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.

  4. Toby says:

    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:

    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?

  6. Michal Fizek says:

    Hello,
    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:

      CLion relies on it’s own parser, not clang. We are going to implement clang annotator (https://youtrack.jetbrains.com/issue/CPP-81), 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: https://youtrack.jetbrains.com/issue/CPP-1263

      • John says:

        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:

          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:

            Thanks for the detailed reply :)

          • KB says:

            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:

            If you could provide a CPU snapshot for us (https://intellij-support.jetbrains.com/hc/en-us/articles/206827577-Reporting-performance-problems), 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:

        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:

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

          • Alexander Kirillin says:

            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:

    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 =))

  8. Per Larsen says:

    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!

  9. Benjamin Mayr says:

    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!

  10. Anindya Chatterjee says:

    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:

      To provide CMake compiler paths, go to Settings | Build, Execution, Deployment | CMake and pass as CMake options:
      -D CMAKE_C_COMPILER=
      -D CMAKE_CXX_COMPILER=
      In case CMake fails to find some path to clang libs, etc. you can also set there environment variables:
      CC=/usr/bin/clang
      CXX=/usr/bin/clang++
      Please, share if it helps.

Leave a Reply

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