CLion 2019.1 is Here with Embedded Development, ClangFormat, Memory View, Injected languages, Custom Themes, and Much More

We’ve got great news for you! This year’s first major update, CLion 2019.1, is public!

To update right away, use the Toolbox App, snap package (on Ubuntu), our website, or the patch-update from the latest build of 2018.3. What are you waiting for? :)
CLion 2019.1 released!

As announced earlier, our main areas of focus this year are IDE performance, expanding Clangd leverage, and Embedded Development. This update makes headway in all three areas:

Read on for more details and check out this short What’s New video by Phil Nash:

We can provide you with a free 30-day trial to test out all these features for yourself before committing to a subscription.

DOWNLOAD CLION 2019.1

Wider integration with the Clangd-based language engine

As our main focus on wider Clangd integration hasn’t changed, we devote a lot of effort to developing our complementary Clangd-based language engine. Where possible (from the functional and performance point of view), we reimplement actions on this engine, still leaving the option (for now) to switch to CLion’s own engine for such actions.

From a user’s perspective, we see that it makes the editor more responsive. Another step we’ve taken towards wider Clangd integration is that we now leverage Clangd to identify places that need quick-fixes. This means that the Clangd-based language engine can not only be used to identify potential breaches in the code and show an error or warning, but also to provide the location for a quick-fix. Note though that the actual quick-fix is provided by CLion.
Clang fix location

This second step however had some drawbacks, and as a consequence a few of the quick-fixes were temporarily removed (CPP-15243).

Amongst other things, the error-annotator has been improved, and can show more detailed error message taken from Clang. Useful cases for this includes debugging a failed overload resolution, where Clang can provide a detailed reason for the substitution failure:
Clang errors

Our C++ language support team is also working on the unique code checks provided by CLion and implementing them on Clangd. This time the Member function can be static check. It analyzes the method body, trying to check if it depends on this or not:
Member static

Improvements for CLion’s own language engine

IDE performance

Even as we are working on the Clangd-based engine, we’re still investing lots of effort into improving our own language engine. First, we aim to boost the IDE’s performance, where Clangd is not yet applicable, and second, we increase the accuracy of the refactorings, which still cannot be moved to the Clangd-engine, at least not in its current state.

Importantly, we’ve reduced the initial indexing times when you create a new project or open one for the first time. The idea is that CLion can now reuse the symbols built already for some other recently opened projects, as long as they fit for this project. A typical case is with STL or Boost libraries, or any other custom library you are widely using in your current and new projects. We plan to work further on this feature and expand on it in the future.

More accurate refactorings

We have been going through and updating the refactorings one by one, and this time we got to work on Extract. To make sure the result is accurate, we worked on making it respect the std:: namespace qualifier, template specialization and template parameters, and type aliases.

The Rename refactoring has also had some special attention given to it. Now the Rename called on a file doesn’t silently trigger the associated class/struct rename, but instead shows a popup suggesting this option. And vice versa!
Rename class

Besides, when the header file is renamed, the header guards are updated accordingly if they are used in this header file and the header guards style template used includes the header file name.

First steps towards Embedded Development

If you develop for STMicroelectronics boards, you’ll be happy to find that CLion now integrates with STM32CubeMX:

  • CLion’s new project wizard suggests you creating an STM32CubeMX (.ioc) project or you can open an existing project of this type in CLion.
  • Later you can start STM32CubeMX directly from CLion at any time to update board settings and generate code.
  • CLion will also generate a corresponding CMake file for your .ioc project to work with it correctly and suggest selecting the board config.

If you’ve ever tried the OpenOCD + STM32CubeMX plugin, the functionality is very similar as we now bundled the updated version of this plugin into CLion.

The second part of the plugin can be useful to any embedded developer, as it provides the integration with Open On-Chip Debugger. Use the new Run/Debug configuration template, ‘OpenOCD Download and Run’ to debug on your microcontroller.
OpenOCD

Learn more about the integration and necessary setup in this detailed blog post.

Adjust CLion to your code style

ClangFormat

The ClangFormat tool is widely used in the C/C++ world and is even regarded as a standard by many developers. Quite often open source projects store a .clang-format config file in their repository. Now, when you open up such a project in CLion, the IDE will detect the config file and will suggest that you switch to ClangFormat. Which means, ClangFormat is now integrated into CLion as an alternative formatter! It affects all the IDE’s actions, so you can switch to it completely.
ClangFormat

There is also a general per-IDE switcher for ClangFormat in Settings/Preferences | Editor | Code Style. Read all about it in our dedicated blog post.

C/C++ naming

PascalCase for classes and structs, camelCase for member functions and variables, SCREAMING_SNAKE_CASE for macros and constants, snake_case for global functions, ‘E’ as a prefix for all enum types – all these naming conventions. CLion understands your pain and now provides the corresponding settings in Settings/Preferences | Editor | Code Style | C/C++ | Naming Convention and respects the selection in all completion, code generation, refactoring actions, and quick-fixes.

You can also select a naming style (and other code style settings) from a predefined scheme: Google, LLVM, Qt, and others are available. Or, you can enable the Inconsistent Naming inspection to have the IDE warn you about any problematic names and then give suggestions for a more accurate name with a quick-fix to replace all the usages for you.
Naming convention

Header Guards style

What do you usually use in header files – pragma or header guards? By default, CLion generates header guards (you can change the header file template to use pragma in Settings/Preferences | Editor | File and Code Templates), if you are a header guard kind of person, then you’ll be happy to know that CLion 2019.1 comes with a new ability to configure the header guards style:
Header Guards settings

The template supports Apache Velocity syntax and uses some predefined variables such as ${PROJECT_NAME}, ${PROJECT_REL_PATH}, ${FILE_NAME}, ${EXT}, etc. If you wish to use a more standard style, select one of the predefined styles option (same as for the naming conventions).

Custom build targets and run/debug configurations

Many of you have been asking us recently to provide you with the ability to build projects using some kind of custom command provided in the IDE. There have also been a lot of requests for the ability to run/debug binary in the IDE by pointing a Run/Debug configuration to the custom executable. This would be especially useful for compilation database projects, which are supported in CLion (and can be extracted from nearly any build system). So in CLion 2019.1, this is exactly what we have done.

To build your project with a custom command, create a Custom Build Target in Settings/Preferences | Build, Execution, Deployment | Custom Build Targets, where provide a toolchain and Build/Clean commands:
Custom target

To run or debug a custom configuration in CLion, configure the Custom Build Application configuration in Run | Edit Configurations…, where you can provide a custom target, executable, the program arguments, etc.
Custom configuration
Learn more about the details of how this all works in our webhelp.

Debugger enhancements

Memory view

Starting from CLion 2019.1, you can dump the raw memory behind a pointer when you are debugging. There is even more to this: open the memory view while debugging and follow the changes to the memory during stepping:
Memory View

This is still a work in progress. For example, you can expect the ability to dump the arbitrary memory address in the Debug mode coming soon in the updates.

Disassembly view

The Disassembly view has been improved to show the information there categorized by function. And it now works for LLDB, so LLDB and GDB are both covered now.
Disasm view
Use Force Step Into (Shift+Alt+F7 on Win/Lin, ⌥⇧F7 on macOS) on a function with no source code to open this view:

Mute variables

Variables can take a significant amount of time to calculate, and this may be especially performance-critical when stepping through the code. If you need to keep an eye on the variables calculations, it can be a huge amount of work and may not even be needed in the end. In such situations, you can now Mute variables using a general per-IDE switch. And when you do need to, you can apply the Load option to calculate the particular variable on the current step.
Mute variables

Injected languages

String literals with pieces of code can be treated as real code pieces. This means that code highlighting and language-specific intentions and actions can be applied to them. Typical examples where this could be useful would be SQL or HTML strings, or regular expressions.

To temporarily inject a language, press Alt+Enter and apply the intention “Inject language or reference”, select the appropriate language, and you are done! Now you can edit code fragments in the dedicated editor section or apply a specific action, for instance, you can check whether a string matches the RegExp right in the IDE:
Inject language
Isn’t that handy?

Brighten up your IDE with custom color themes!

If the Default white and Darcula themes are not enough for you, then why not go ahead and create your own custom one! Every color of every item in your IDE, from the icons and radio buttons all the way through to the arrows, are now all totally configurable. Adjust them to your own personal preferences and then save it all as a new theme plugin. Learn how to do it in this tutorial.
Color themes

Rust plugin update

The IntelliJ Rust plugin provides support for Rust along with the Cargo build system and debugger in CLion. This version gives it a massive update:

  • Profilers are now supported for Rust: DTrace on macOS and Perf on Linux.
  • Out-of-scope items are suggested in code completion and trigger the auto-import when used.
  • Rust language injection into code snippets in doc comments is now provided.
  • Various improvements to Cargo check annotator and LLDB and GDB formatters.

Stay tuned for a detailed blog post on the recent changes (or subscribe to our Rust news here in the blog).

Other enhancements

Other improvements include a new Recent Locations popup, which provides an overview of all the locations that you’ve visited in chronological order, and an updated versions of bundled CMake (3.13), the bundled LLDB (7.0.1), and the latest supported Cygwin (3.0).

Besides, the process of building CLion’s plugins was simplified by publishing CLion as a Maven dependency to be used by gradle-intellij-plugin (since version 0.4.2).

That’s it! Please go and give all the new improvements a try and let us know what you think.

DOWNLOAD CLION 2019.1

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

101 Responses to CLion 2019.1 is Here with Embedded Development, ClangFormat, Memory View, Injected languages, Custom Themes, and Much More

  1. wumo says:

    Great! Now my only wish is the MSVC Debuger.

    • Anastasia Kazakova says:

      Thank you. It’s under development now. We hope some preview (very early bird) will be ready for 2019.2

      • Anony Mouse says:

        Wow! Will that be cdb (which sucks about as much or more than gdb), or the REAL MSVC debugger? This would be huge!

        • Anastasia Kazakova says:

          It’s LLDB-based debugger implemented from scratch by our team.

          • Bodie says:

            I can’t wait! Are there any plans for the debugger to support Rust well on MSVC? Now that would be a slam dunk. Lack of a good MSVC debugger integration is one of my major reasons not to use Rust.

          • Anastasia Kazakova says:

            No plans for Rust at the moment. And mind, it’s not an MSVC debugger integration. This is impossible due to licensing reasons. We do implement a debugger from scratch.

  2. llvim says:

    compilation database is not support with postgress project, pretty strange

  3. jerryouyang says:

    Finally! Thank you!

  4. Kirill Sapozhnikov says:

    Hi, congrats on release. I’ve noticed an issue with update. After update clangd server doesn’t work. It launches and crashes, as I can see from process explorer. As a result all code resoving features don’t work. And I can’t open any new files – they are constantly loading. Restarting CLion doesn’t help. To fix I have to turn off clangd in settings, restart CLion, then turn on and restart again. Not reproducable, unfortunately.

  5. Tano says:

    How do we disable the clangd memory indicator enabled by default in the EAP?
    Thanks

    • Anastasia Kazakova says:

      It’s disabled by default in the release. And is controlled by Preferences | Appearance & Behavior | Appearance | Show memory indicator

      • Tano says:

        I want the old memory indicator(very useful), but without the clangd one.

        • Anastasia Kazakova says:

          What’s the purpose of having one w/o another?

          • Tano says:

            That toolbar is already overcrowed and the CLion memory really shows something (1500 of 2000M) and I constantly press it to clear the memory but the clang one is always (or most of the time) at 0-100M, so almost useless.
            Also it’s funny that they have different formats, one is “100/200M”, the other is “100 of 200M”

          • Anastasia Kazakova says:

            For C++ IDE I think both memory indicators are worth looking for if you suspect some issues and turned them on.
            Regarding the format, you are probably right and we should unify.

  6. Felipe Zacani de Mello says:

    Excuse me if I sound harsh, but… as I really wanted to use CLion, just because I’m a fan of your tools, I still feel stupid trying hard to learn how to include a simple lib in a hello world project. Trying to find out how to create build configurations, like release and debug, architecture variants. Learning how to properly debug something on windows (and installing a lot of tools I won’t use for anything else to support that).

    I gave you this advice before, and feel like you didn’t read it at all. Download simple, free IDEs and try to compare them with yours. Start with QtCreator. If I have to stop and learn how to do basic IDE tasks, then CLion doesn’t even beat MS Code with a couple of plugins.

    • Anastasia Kazakova says:

      If you have CMake project, which is the most popular project model in the cross-platform C++ dev, then it’s not an issue to add a library or create a new target. CLion then gets it automatically, and create corresponding Run/Debug configurations for your targets.
      If you want smth more specific, custom and complicated, then some UI is there to configure, and it’s the same as it goes in other IDEs.

      We feel that for example with CMake projects, it’s much easier to start in CLion, than let’s say in QtCreator, as you need nothing except pointing to a top-level CMakeLists.txt file in CLion.

      Windows platform is maybe more tricky, but for cross-platform platform projects it is so even w/o CLion if you are not using VS toolchain.

      • HGH says:

        QtCreator is horrible with CMake projects.
        VSC has a free CMake extension but it is well free… Its development appears stalled. The only viable alternative appears to be VS2019 for CMake but it is just for Windows and it gets broken all the time. Its CMake support is still not mature.

        • Felipe Zacani de Mello says:

          Yeah, and guess what? QtCreator doesn’t depend on an external tool to build a simple hello world. Besides that, last time I checked, it was just like Clion. It gives you a CMakeLists.txt to edit and good luck, champ. I mean, what is the problem with that? Everyone is a cmake wizard nowadays.

      • Felipe Zacani de Mello says:

        Cmake IS the problem here. News for you all: not everyone wants to spend time maintaining their projects with a text file. What about build configurations? What about multi platform management? What if my project uses 200 libraries? I could spend the night typing “what ifs”.

        But the most important reply to your comment is: if its so simple, why not providing a proper ui, so the developer won’t have to know your build tool at all?

  7. Tano says:

    So many options, so many features, wow, but I still have input lag when I edit a 5000-lines file…in 2019.
    Also, when the file is very small and I include curl.h (from cURL), it’s totally disaster, the text has 2 seconds delay.
    Yes, I opened bugs for both 2 years ago…

    • Anastasia Kazakova says:

      Please list particular links to the tracker, so that we can recheck.
      We do constant job on IDE performance improvement, all these Clangd changes are in this direction, so I can’t say we are not giving any attention to it.

      • Chris says:

        Any time I have medium sized projects, or moderate use of templates, Clion causes my fans to spin at max speed and code completion to fail. 2015 MB pro.

        • Anastasia Kazakova says:

          We are aware of many performance issues and work on them with top priority. Anyway, will be useful if you collect CPU snapshot and share with our support.

          • Chris says:

            I can’t do that due to proprietary nature of my project. To reproduce this, I would recommending undertaking a medium scale project (several 100K loc), that utilizes several libraries (curl), while making use of modern c++, and light but consistent use of templates. It doesn’t take much to cause it to do this. I often see 300% or 400% CPU usage, and code completion / refactoring / other features grind to a complete halt while my fans spin like crazy. I notice that using auto messes up the type hinting system… which indicates that your model for types is not advanced enough to offer useful suggestions. It is likely the same problem that is causing issues with templates.

          • Anastasia Kazakova says:

            Yes, we see various issues in various medium or heavy projects. But they are not caused by one problem. We have a set of known issues we are working on and definitely some we’ll discover later. That’s why we are usually asking about snapshots and code samples. In order to get the nature of the particular problem case.

    • Michal says:

      I have the same. I also noticed that copy/paste a few characters in a few thousands lines file can take up to 10 seconds on Xeon workstation with 64 GB. It seems to be an issue with code formatting as pasting without formatting is fast.

      • Anastasia Kazakova says:

        Do you have a CPU snapshot of such delay? Do you have a code sample you can share? Would be very interesting to check it out and dig further in what’s going on in our formatter there.

  8. Christian says:

    Why can’t i explore the memory view manually or show a stack variable in memory view? I wish Clion’s debugger support would be as good as eclipse’s :/ otherwise Clion is a great IDE but it lacks debugging support.

    Also it would be nice to have a disassembly view that you can explorer as you wish, i.e. next to your c++ code you have the disassembled view so you can check what asm code was produced by the corresponding c++ code (of course this will not work pretty well with -O2 -O3 or even -O1 but it still is a very valuable information).

    All in all i like the update but i am still hoping for better debug support and faster autocomplete which takes ~1 second for large header files on my machine (quadcore i7).

    • Anastasia Kazakova says:

      By explore manually, do you mean getting memory view by entering a particular address into some UI?
      Local variable – works, if it’s a pointer. We’ll later add other cases.

      Disassemble on demand is planned for the future releases.

      Completion speed-up is also planned, but it’s worth sharing a CPU snapshot with us for the case when it takes 1 sec.

      • Christian says:

        Hello Anastasia,

        thank you for reply.

        Yes, by manually exploring i mean that you can go to any arbitrary address (i.e. stack and heap memory) and watch it in the memory view.

        The plans do indeed sound very nice and promising, i am looking forward to them.

        Have a nice day!

        • Anastasia Kazakova says:

          Thank you! Memory view UI/UX was kinda experimental in this release, and we definitely see issues and plan to improve.

  9. Roman says:

    Size of codebase I had to work with grows faster then Clion performance :(

    • Chris says:

      Been my experience as well. I’m not sure they understand what it means to have millions of lines of code in thousands of modules. Marking everything as a library isn’t a real strategy. Their platform needs to dramatically change it’s efficiency to be useful at scale.

      • Roman Popov says:

        In my opinion CLion should learn something from QtCreator. For the project it takes Clion 20 minutes to “Update symbols & Build Indices”, QtCreator is ready to work in __seconds__. And it is really ready to work : auto-completion works, Locator works, switch header/source works!

        Yes, maybe super smart features like global refactoring or search for string literals require 20-minute analysis of project (When Clion completes 20-minute parsing it becomes best in the world to do this unusual navigation). But please let me code immediately, while doing this long parsing in background.

        • Anastasia Kazakova says:

          Have you share some CPU snapshots for such a case with us? Just to check what CLion does there.
          Anyway, CLion doesn’t parse files not included into project/CMake. However, some pre-processing is done for libraries. Any particular case should then be deeper investigated.

          • Roman says:

            Yes, already did https://youtrack.jetbrains.com/issue/CPP-6621

            For this project:
            QtCreator Open CMakeLists, parsing – 20 seconds
            Clean Build – 10 minutes
            Clion Onen CMakeLists, Updating symbols – 20 minutes

            So what QtCreator does in 20 seconds, Clion does in 20 minutes

            After initial parsing Clion performance for this project is good enough. So I work with 2 IDEs open. I use QtCreator when Clion is parsing, when Clion is ready I switch to Clion.

          • Anastasia Kazakova says:

            Let me just ask – in which situations it’s that slow: initial indexing or reopening of the already indexed project, or switching branches? This is three different situations. So need to get it clear. About all three just to explain:
            – initial indexing can indeed be long. Should be optimized anyway (for example, in 2019.1 we’ve added an ability to reuse the indexed external libraries like Boost or STL in some cases), but it should happen only once.
            – reopening should be quick. If not, that’s a bug. We need to investigate
            – switching branches is a known issue, that has its roots in IntelliJ platform architecture and VCS implementation. We are currently working on improving the case. Hope to get good results in 2019.2 and 2019.3 releases

          • Roman says:

            And it is a deal breaker for many in my organization. When I ask people about Clion, answer is usually “Yeah, I’ve tried. It’s so slow.”

          • Roman Popov says:

            >> Let me just ask – in which situations it’s that slow

            1) Initial opening
            2) Switching branches

          • Anastasia Kazakova says:

            The snapshot in the comments (in the ticket) is it for the initial opening? Can you please get one for that stage on 2019.1?

          • Roman Popov says:

            Yes, it was initial opening. Uploaded new snapshot.

          • Anastasia Kazakova says:

            Yes, I see your comment in the ticket, thank you. We’ll check it out

      • Roman Popov says:

        I don’t know what Clion does exactly, but I suspect it parses files that are not included in CMakeLists (I suspect this because it does arbitrary text navigation that fast, so it should have some index for every text file). And this can explain why it is so slow in building symbols.
        In organizations that have monorepos, this approach fails.

  10. HGH says:

    Does CLion support Kotlin native? Does CMake support Kotlin native? Does Android/AS support Kotlin native?
    What about mixed C/C++, Kotlin CMake projects, libraries?
    Do you consider such options to make these happen?

    • Anastasia Kazakova says:

      Kotlin/Native is supported in CLion. With Gradle, not CMake. And you can do mixed projects for sure and work on them in CLion.

      • HGH says:

        Let me clarify my question: Do you plan to make a CMake only Kotlin support happen? This means support Kotlin in CMake? CMake is nasty enough on its own and I’d rather have to deal with one build system instead of two. I have a CMake project and I also have a wrapper project to compile it for Android – Gradle + CMake is too much (too slow)! I wouldn’t even start that I find the C++ support in Android Studio underwhelming – like how error messages are handled, build system output etc…. it is just bad.

        • Anastasia Kazakova says:

          We don’t plan to support CMake for Kotlin/Native. Kotlin/Native is a part of Kotlin Multiplatform and it makes it even harder to support such projects in CMake. So we moved to Gradle.

  11. Jonas says:

    Nice release, but switching from header to cpp file still takes forever if it event get found at all. Any other devs with this issue?

  12. Steffen says:

    CLion 2019.1 drives me crazy. I opened a 2018.3 project and got a lot redefenition warnings for structs and functons. Only header files without a related src file are affected, it is gone when I create a related empty .c file and just include the header. Pls fix this! Have to downgrade CLion meanwhile.

  13. Steffen says:

    There are already some open:

    https://youtrack.jetbrains.com/issue/CPP-15464
    https://youtrack.jetbrains.com/issue/CPP-15507

    Ddifference is I use C instead C++.

  14. HGH says:

    Double post! Sorry!

  15. blackj0221 says:

    “It’s LLDB-based debugger implemented from scratch by our team.”

    Is there any plan to allow to use that debugger for other toolchains? (e.g. WSL)

  16. Yiannis says:

    Thank you for yet another great release, especially about the embedded development features. It would be really cool if you could also add support for AVR as I’d really like to drop atmel studio in favor of clion. Atmel studio is not that awful, but it’s windows only (I prefer working on Linux) and honestly, whenever I switch to a different IDE, I realize how much I miss the power of the IntelliJ platform.

    • Anastasia Kazakova says:

      Thank you. We’ll consider that.

    • Elmot says:

      Can you, please, describe your tool set (toolchain, debugger, flashing probe, target chip name etc) and share a demo project, which uses that all. This may simplify things for us.
      I think AVR-GCC based projects may be done with CLion already, thought the setup may be a bit complicated.

  17. Shane says:

    When using a remote toolchain, the compile commands db doesn’t get parsed correctly.

    Clion expects the directory paths and the compiler to be present on the local machine instead of on the remote machine. Hence nothing indexes or syncs correctly and there is no intellisense.

    If a remote toolchain is configured, surely it should be using the remote system when parsing compile_commands.json?

  18. Shane says:

    To be clear, it doesn’t appear that CLion supports remote development with compile_commands.json projects?

    i.e at least the following issues are present, despite using a remote toolchain:

    1. Directory paths from compile_commands.json are expected to be on the local system.
    2. compiler and arguments in compile_commands.json are expected to be on local system and executed locally.
    3. clangd is run on the local system instead of remotely, so cannot use compile_commands.json correctly or read system headers
    4. It does not seem possible to open project files over sftp

    It would be great if there was a mode that just ran clangd, build tools etc via scp and accessed files via sftp etc, honouring the remote host configuration.

    • Anastasia Kazakova says:

      yes, it’s currently not supported. We are aware of the issues. Remote toolchain works now only for CMake.

      • Alexey says:

        How about the following scenario: the project is developed and built (with makefiles and compilation DB) on the same local machine and the binary runs on a remote machine (different architecture) and with GDB server interface. The remote machine runs a raw binary with no symbols/sources; we provide the path to the symbols to the local LLDB we use for debug (which connects to the remote GDB server).
        Can we expect to be able to debug such a setup in Clion?

        • Anastasia Kazakova says:

          This is already possible, feature is called Remote Debug with gdbserver: https://www.jetbrains.com/help/clion/remote-debug.html

          • Alexey says:

            Thanks, will definitely give it a try!

          • Alexey says:

            I seem to be stuck at telling CLion how to open LLDB. The way we do it today (on MacOS) is:
            “xcrun lldb “.
            In CLion I can either use the built-in GDB (no LLDB option?) or a path to an external GDB – but no way to add parameters?

            The built-in GDB returns: com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$GDBCommandException: Remote failure reply: E01

            Directly using our LLDB results in:
            lldb: unrecognized option `-interpreter=mi2′

            When I tried to bundle our command above into a script and tell CLion that it’s GDB, it waits for a while and then times out.

            Please advise what else can we try?

          • Alexey says:

            The command syntax was eaten by your comments system. It is

            xcrun custom_parameters lldb path_to_target_file

            Probably need to find a way to call this from within CLion?

          • Alexey says:

            Hi Anastasia, any thoughts on the LLDB opened with xcrun (see details from April 11 in this branch)?

          • Eldar Abusalimov says:

            Hi Alexey,
            Sorry for the late response. I’m afraid it’s not possible to use LLDB from CLion for debugging via a gdbserver (https://youtrack.jetbrains.com/issue/CPP-7048). Meanwhile, we suggest using GDB for debugging remote targets. The built-in GDB is compiled with multiarch support so it’s capable of debugging most of embedded targets supporting gdbserver.

            What is the exact target arch you try to debug?

          • Alexey says:

            We’re working on something proprietary, so I doubt standard GDB server will manage. I did try it, however, as noted above, and got:
            com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$GDBCommandException: Remote failure reply: E01

          • Eldar Abusalimov says:

            I see. The remote end doesn’t have to be a gdbserver, actually, it can be anything supporting the standard GDB remote protocol, like Qemu or some JTAG monitor.

            So you’re saying that this is a custom architecture, and you only have an LLDB port for it, but not GDB, do I understand that correctly? If you use a custom build of LLDB for debugging your remote target, I’m afraid CLion doesn’t support that, since we only integrate with our bundled LLDB binary.

          • Alexey says:

            More or less. It’s ARM based, so I’d still expect some basic things to work. As I understand, “GDB-Server” reports back the PC (and the registers?), and CLion, through GDB, makes order from it and finds the correct place in the source code, right?
            Why does it fail with an exception, then?
            Is there any way to help the built-in GDB find the architecture that’s best matching to ours?
            Does it discover it during its handshake with the GDB server (which is probably the part that fails)?

          • Eldar Abusalimov says:

            The best way to investigate this is to collect debugger logs, that contain all the commands sent to the debugger by CLion. Please follow the instructions at https://intellij-support.jetbrains.com/hc/en-us/articles/206560589-Debugger-doesn-t-stop-on-a-breakpoint-Debugger-shows-Command-timed-out-What-to-do- to enable the logging, then reproduce the error, and send the resulting idea.log to clion-support at jetbrains.com with a reference to this comment thread. Thanks.

          • Alexey says:

            Will do, thanks!

  19. Ernst says:

    does a custom build work for local projects only?
    I’ve specified toolchain remote (and configured scons build) but when I perform the compilation it tries to do this locally.

  20. Johnny Depp says:

    Hi Linux C programmer here. I am using your tool with a project written in C that contains about 50-60 files. The tool is perfect for this. I managed to add support for plain old makefiles as this project requested. I used the 2018 version which sold me over any other IDE.
    However, switching to 2019 my annoyance level went up big time. I am loosing productivity big time.

    1. Where did Optimize Imports go? I cannot find it anymore. It is not in the menu and the keyboard shortcut does not work anymore.
    2. Code folding: why any brackets from if, while, do can have their own code folding icon on the side? I need to learn a new shortcut to do this…
    3. The TAB functionality: Why does it behave differently when I tab freely in the empty spaces, but once I am getting to align a piece of text, it actually jumps to the parameters of the function. I do not have a problem with this if it was a Shift|Ctrl|Alt TAB, but not TAB.
    4. Now the most annoying: I am trying to copy and paste text from one part to another. The select using the mouse selects the text, basically an area, the cursor becomes as tall as all the select area and when I try to copy this selection in some other area if the free area is not as tall as the area I am copying it, it will jumble with the text that should be pushed down. So if I only have one line free where I want to paste, the editor will put the lines in parallel with the one I paste.

    Please, please, please, stop reinventing the wheel and not making it round. please don’t replace expected functionality with something unexpected.

    • Anastasia Kazakova says:

      Hi,

      I’m sorry you feel this way. Let me address your points one by one:
      1. Optimize imports had many-many false positives, so we temporarily removed it. We plan to rework and put it back in 2019.2 or 2019.3
      2. We on purpose didn’t add gutter icons to fold control blocks. You can fold them with shortcut and then the gutter icons will appear. Otherwise, the left gutter becomes too overcrowded.
      3. In your keymap you can remap the “Next parameter” action to any other key you prefer instead of Tab.
      4. I’m not sure what happens to your cursor there, could you maybe record a video with all the keystrokes you hit during it?

      • Johnny Depp says:

        Thanks for your comments.
        Not sure if I can record a video, but here the the steps:
        1. Select an area of code (multiple lines) using the mouse; the selection will not select full lines, just the area. Do a Ctrl C to copy the code.
        2. Move to a place where you want to paste it, preferably between 2 existing lines, call them ‘first line’ and ‘second line’.
        3. Paste. See what happens. (Instead of the code to go sandwiched between the 2 lines, and the second line to go under the pasted code, the second line goes in parallel with the pasted code).

        • Alexey says:

          May I guess you have the Column Selection Mode enabled (by mistake)? When it’s not enabled my mouse selects only full lines. To enable/disable look for it in Edit menu, not sure of the shortcut in Linux, it’s CMD-Shift-8 on Mac, very useful!

  21. Naveen Swamy says:

    With the 2019.1 update, Application Template in Run/Debug Configuration is missing.
    I cannot debug a native application anymore? something like this https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=109445865#CLionsetupforMXNetC++developmentonMacandLinux-Step6.DebuggingMXNetbackendcodewithPythonfrontend

    Is there an alternative to this? I tried Custom Build Application but that needs a Custom Build Target and I cannot choose a CMake Target that I already have. seems like a regression.

    • Anastasia Kazakova says:

      Since that was a CMake related application, we renamed it in 2019.1 to CMake Application. That’s what previously was called Application, and was not really accurate as it requires the CMake target.

  22. Ryan Cheu says:

    I really think the team needs to focus on performance over everything else. There’s enough features in the IDE already, but it really needs is less freezing. I could probably convince most of the C++ engineers in my company to switch to it (20+ people) if it just didn’t freeze typing, but it does not seem like performance is getting any better. If anything, I get more freezes in this version.

    I’m not even asking for it to do operations quickly, I just want to be able to keep typing while it does whatever is taking so long in the background.

    • Anastasia Kazakova says:

      We do treat performance as a top-priority task. And in some areas the performance is indeed getting better, also many freezes were eliminated. However, there are still places that require more work (currently planned) and some huge architectural changes (in progress, but not a one-release-cycle thing definitely). So it’s sad to know that for you the performance is worse. Maybe you can report the thread dumps to us (when UI is freezing they are created automatically in the IDE’s log directory)? We’ll investigate and try to help.

Leave a Reply

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