Broken in CLion 2023.1 #81
Comments
|
The same happens in Pycharm Pro 2023.1. |
|
And another exception: |
Noam-Dori
added a commit
that referenced
this issue
Apr 18, 2023
Signed-off-by: Noam Dori <TheNODO55@gmail.com>
|
I replicated the error. The error is unsurprisingly caused because the library is being disposed, then the disposed library is used again, which causes errors like a NPE would, hence why nothing is working. The code no longer stores libraries as they are constantly disposed, and the fix was tested on CLion 2023.1 |
Noam-Dori
added a commit
that referenced
this issue
May 1, 2023
|
Hi @peci1, I believe the major bug was dealt with by the above commit. Does it fix the issues you encountered? |
|
Thanks it helped somewhat. Now it sometimes work. But sometimes it does not, usually without any error message. I've noticed 3 "modes" of (non)-working:
These three modes seem to randomly happen even in the same project. I haven't noticed any pattern in it. I tried launching CLion with just a single project loaded (I usually have more), I tried invalidating caches, nothing works in the sense of getting the plugin predictably to any of the three modes. In mode 2, when I hover or Ctrl+Click a message definition in a message file, I get an NPE: Right now, I have a running CLion with 3 projects opened, each in a different mode: Mode 1:
Mode 2:
Mode 3: |
|
Playing with Additional package path seems to semi-randomly switch between the modes. Sometimes even Reload CMake project does. However, there is no pattern in it - even two projects from the same metapackage (and workspace): one has mode 1 when I clear the additional packages path, while the other has mode 1 when I fill the source path to the underlying workspace. |
|
When opening a project that was never opened with this plugin, I also get assertion error: |
|
And I got this once (but only once): |
|
I think I can help you with the pattern behind this flavor of issues. Since packages are completely independent from the workspace scope (the workspace doesn't have to be the project in its entirety, and obviously the core ROS files are outside the workspace), the plugin needs to create different libraries which are in turn used to run searches and indexing. When the "workspace" library ( When the "ROS" library ( Adding additional package paths extends the workspace library, so that would explain why it works. From my experience the rest of the code works fine, but the library indexing has many issues. The bugs you raise (and raised in the past) help me find those issues which is something I appreciate. Message files are one of the few features that do not rely on packages at all, so that explains why they are the only things that work when the libraries don't work
Was the message you clicked on a "ROS" message or from your workspace? If it was a ROS default message, that would explain why it would crash. |
Closed
The message I tried had both standard library types (Header) and custom types. Header was not red and caused the NPE. The custom messages were red (missing), and did not cause the NPE. I hope this helps... |
|
The first header in message files, just like in ROS, receives special treatment. The same applies in the plugin, and the plugin will not annotate the first header and will redirect to std_msgs/Header automatically, even if it does not exist (It should always succeed though as it is a standard ROS message) |
Hmm, but I don't see any errors logged... |
|
There are multiple ways the library can decide to not load, even without errors. For example, in the video you sent in this thread it fails without error: it loads (you can see it in the bottom of the external libraries tab) then immediately disappear, probably because it is being incorrectly disposed. I do not know why this happens, but I hope that once I manage to consistently replicate a scenario where this happens I will resolve it |
|
Since the principle bug reported here was fixed and CLion doesn't crash all the time, I think I will close this particular issue It seems there may be more sources of this sort of issue, and I want to tackle them all together. If you want to, you can write that stack-trace in issue #84 where I will tackle this issue as a whole |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I decided to give the plugin another go seeing the current development efforts. But it does nothing.
To Reproduce
Steps to reproduce the behavior:
Environment Information:
Stack Trace
This is a huge one:
I can also trigger an NPE by Ctrl+Clicking a message type definition in a .msg file:
And another one when ctrl+clicking a message field name in a .msg file:
Screenshots
I can see the "ROS" item appear shortly in External libraries on startup, but then it disappears and never appears again.
ros-integrate-bug.mp4
Another issue - when I right-click a .msg file and choose "Override file type", I get 3 options named "ROSPkt (from 'ROS Support' plugin)". This is not very helpful.
The text was updated successfully, but these errors were encountered: