Custom language resolver "resolved in the context of <target>"
已回答
If i load a C++ file, in the bottom right-hand corner of the IDE it will say something like "this file was resolved in the context of " a build target.
I'm working on symbol resolution for a custom language plugin and would like to know if there is a way to gain access to this "resolve context"?
Thanks.
请先登录再写评论。
Hi Jeffrey!
Before digging into the details I'd like to mention that the C++ support in CLion is undergoing a major rework, and chances are the C++ integration part of your plugin will become obsolete in a year or so (this is by no means a guarantee, and I can't give you exact ETAs or transition paths, but I still want to warn you about this).
If you're OK with that - I'd like to know more about your use case - do you want to the the build system target, or compilation commands, or C/C++ PSI and symbols corresponding to a specific configuration?
Hi.
Sorry, my last message might have been a little unclear.
I'm building an assembly language plugin, https://plugins.jetbrains.com/plugin/20274-vax-macro, and working on resolving references, the performance is terrible, bordering on unusable because i currently have to search every single .mar file in the project directory.
The relevant files that i need to search _are_ listed in the build target information. If i had access to that list of files, the performance would be much better.
Switching away from my plugin, When it comes to .cpp files, the IDE is getting that "resolve context" information from somewhere, which lists all the targets that reference a particular file. I'm guessing it also has a list of all files referenced by a particular target.
I'm wondering if there is any way of providing that information to my assembly plugin, for .mar files.
Let me know if that clears things up.
Thanks.
It's more clear now, thanks!
Unfortunately, I don't think there is a way for you to get exactly what you need - the specific set of files attached to each CMake target is not persisted for performance reasons, and only a post-processed version is stored.
Still, here are some things that may help you:
There is a sample open-source plugin that demonstrates some API usage (while collecting diagnostic information):
You can inspect all of it by calling the "Get C/C++ Diagnostic Information" action.
Likely showstopper for you here is that we don't store non-C/C++ files for "resolve configurations", so it looks like the information about .mar files is completely lost.
However, I'd argue that even if this information would be available to you, it won't make much difference i.e. in case all the files are attached to the same build target - in this case, it would be not that different from using `iterateContent()` for your language as mentioned here - so hopefully, using project file index with some caching would help.
Please let me know if I misunderstood your use-case and additional info from the underlying build system would still be useful for you.