CLion 2016.2 EAP, build 162.1120.17

Hi,

Another week brings another Early Access Program build with lots of goodies inside. Download the build here, or get a patch-update in the IDE (will be available soon), if you are using the previous EAP build.

Release is coming closer, so if you find any issue at all, please, report it to our tracker. Thank you in advance!

LLDB on Linux

After introducing big changes in the debugger drivers that improved performance and fixed many correctness issues, we continued working on new debugger features. CLion now goes with the LLDB on Linux (in addition to GDB) – version 3.8 is bundled into the IDE:
debug_settings

Attaching to local process thus works with both (LLDB and GDB) on Linux:
lldb_attach_linux
Note, that on Linux to use GDB for attaching to process you need GDB to be selected in Toolchains settings (this is a temporary solution, CPP-7011). On macOS attaching to process with GDB is still not possible.

Comparison, relational and stream output operators generation

CLion provides plenty of options to generate boilerplate code. In addition to constructors/destructors and getters/setters, this EAP build allows you to generate missing:

  • equality operators,
  • relational operators,
  • stream output operators.

These new options are available in the generate menu (Alt+Insert on Linux/Windows, ⌘N on macOS). Generation dialog allows you to select fields to use during the generation. In addition, you can configure:

  • if to generate all the equality/relational operators, or just == and < (this is also configurable under Editor | Code Style | C/C++ settings),
  • if to generate as class members,
  • if to generate in-place,
  • if to use std::tie for the operators implementation.

In case some of the operators are already there, CLion suggests you to add missing ones (and if all the operators are already there, you can replace all the existing with the new ones). Preview of the existing operators is available:
generation

Note, that CLion doesn’t check that class members has its own operators specified.

Doxygen improvements

We continue our work on Doxygen support in CLion. As you may already know, CLion provides you with an ability to generate Doxygen comments stub. This build brings a few settings to configure how these comments will look like. You can select if you prefer @-commands or \-commands style and if you’d like CLion to add brief tag:
editor_settings

Besides, @code/@endcode and @verbatim/@endverbatim tags are now treated as text without any changes in Quick Documentation pop-up:
doxygen_code_tag

That’s it! Full list of release notes are available by the link.

Your CLion Team
JetBrains
The Drive to Develop

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

14 Responses to CLion 2016.2 EAP, build 162.1120.17

  1. Anton says:

    Thank you!

  2. Mikhail says:

    > Release is coming closer

    That’s a little bit frustrating. So many things we are waiting for.
    In particular the most wanted:
    * Project model (CMake): Ability to watch command output during CMake execution (this is even mentioned in https://confluence.jetbrains.com/display/CLION/Roadmap+for+CLion+2016.2)
    * annoying bugs:
    ** guard idiom: https://youtrack.jetbrains.com/issue/CPP-1346
    ** pointer-to-member: https://youtrack.jetbrains.com/issue/CPP-2836
    ** pointer-to-member-function: https://youtrack.jetbrains.com/issue/CPP-2254
    ** actually all 150+ items that alinked to CPP-844 and CPP-1087, the youtrack filter “links: CPP-844 and state:open”

    • Anastasia Kazakova says:

      Thanks for pointing. The story is that we want to release when current functionality becomes stable so that everyone can get access to the new features and important fixes in the stable release asap. Then we’ll continue our work and will be publishing updates delivering bug-fixes and new features. So release doesn’t mean we stop our work after it for a couple of months.
      CMake command output is in development currently and will most likely make it way to one of the 2016.2.x updates. That’s aligned with the roadmap as we’d like to cover it with 2016.2.x releases (including 2016.2 and 2016.2.x updates).

  3. wl.nicholas says:

    This is definitely amazing!

  4. Sebastian says:

    Good job with the attach to local process feature. I was just wondering, is it by any chance possible to automatically attach to the child process after a fork() has occurred in the parent process? I just had a case a few days ago where I would have needed such a feature. If its not possible, then is there an issue for that?

    • Anastasia Kazakova says:

      Should work by attaching using the pid. At least we don’t know any reason why it shouldn’t work. Feel free to try and share the results with us!

      • Sebastian says:

        Yes that will always work, but if I want to debug code that happens directly after the fork, then I must introduce a hack and do something like sleep(30) right after I fork(), then check the return value of fork for the pid and attach the debugger. It would be nice if I could tell the debugger which fork() I am interested in, and it would attach to the child automatically and would stop the child immediately after the fork. I am not sure how difficult that would be to implement in the debugger.

  5. David Zemon says:

    I notice remote debugging was in the 2016.2 roadmap but still no mention of it here. Is it still on the 2016.2 roadmap or is it being postponed to a later release?

    Thanks,
    David

    • Anastasia Kazakova says:

      It’s under development now. If we manage to finish it (at least to get some working solution for most useful cases), it will come to 2016.2.

  6. Alexander Münch says:

    Hi Anastasia,

    any news on these nasty StackOverflowErrors? On JetBrains Exception Analyser the reports are all tagged green “build #Dev” but since three EAP versions there is no fix released :(

    • Anastasia Kazakova says:

      We’ll check. Do you occasionally remember the report number?

      • Alexander Münch says:

        There are dozens of them. Most of the exceptions I reported since build 162.844 are these StackOverflowErrors. For example report #1135313.
        If you can search the reports by reporter you should find them all. If not, just tell me, I can compile a list for you.

        The reports look all similar. Most noticeably in the stacktrace is the AbstractTreeUi spawning some task which recursively calls the AbstractTreeUi again.

Leave a Reply

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