in my quest to get clang-tidy integrated into your favorite editor
(via ycm) I'm hitting one major roadblock. I'm piggybacking on the
existing plugin mechanism which gives me both a way to add extra
Actions to the parse process and hand flags to the plugin for
configuration. This works well for (most of) clang-tidy as it really
just emits diagnostics and FixIts.
However, loading a plugin into libclang isn't easily possible because
there it doesn't export all the clang symbols. Putting all the clang
symbols into the plugin doesn't work either because you'll get
duplicate command line flag registration and everything. My current
hack is to statically link clang-tidy into libclang. This works but
creates an ugly (optional) dependency from libclang into
clang-tools-extra.
Is there any other way to extend libclang without actually modifying
libclang itself?
in my quest to get clang-tidy integrated into your favorite editor
(via ycm) I'm hitting one major roadblock. I'm piggybacking on the
existing plugin mechanism which gives me both a way to add extra
Actions to the parse process and hand flags to the plugin for
configuration. This works well for (most of) clang-tidy as it really
just emits diagnostics and FixIts.
This makes it possible to load Clang plugins in libclang by simply passing
additional compiler arguments to libclang's clang_parseTranslation function.
However, loading a plugin into libclang isn't easily possible because
there it doesn't export all the clang symbols.
I'm not sure I understand this issue. Could you elaborate?
A Clang plugin is supposed to be linked against all necessary Clang/LLVM
libraries already, isn't it? So it should be possible to dlopen the plugin
just fine.
in my quest to get clang-tidy integrated into your favorite editor
(via ycm) I'm hitting one major roadblock. I'm piggybacking on the
existing plugin mechanism which gives me both a way to add extra
Actions to the parse process and hand flags to the plugin for
configuration. This works well for (most of) clang-tidy as it really
just emits diagnostics and FixIts.
This makes it possible to load Clang plugins in libclang by simply passing
additional compiler arguments to libclang's clang_parseTranslation function.
However, loading a plugin into libclang isn't easily possible because
there it doesn't export all the clang symbols.
I'm not sure I understand this issue. Could you elaborate?
A Clang plugin is supposed to be linked against all necessary Clang/LLVM
libraries already, isn't it? So it should be possible to dlopen the plugin
just fine.
Oh I see. I was holding CMake wrong, actually linking all of Clang and
Clang-tidy into the same .so works. This is a bit scary to me because
there are now two clang copies around but it seems to work fine.
Thanks!
in my quest to get clang-tidy integrated into your favorite editor
(via ycm) I'm hitting one major roadblock. I'm piggybacking on the
existing plugin mechanism which gives me both a way to add extra
Actions to the parse process and hand flags to the plugin for
configuration. This works well for (most of) clang-tidy as it really
just emits diagnostics and FixIts.
This makes it possible to load Clang plugins in libclang by simply passing
additional compiler arguments to libclang's clang_parseTranslation function.
However, loading a plugin into libclang isn't easily possible because
there it doesn't export all the clang symbols.
I'm not sure I understand this issue. Could you elaborate?
A Clang plugin is supposed to be linked against all necessary Clang/LLVM
libraries already, isn't it? So it should be possible to dlopen the plugin
just fine.
Oh I see. I was holding CMake wrong, actually linking all of Clang and
Clang-tidy into the same .so works. This is a bit scary to me because
there are now two clang copies around but it seems to work fine.
Thanks!
Nope. Didn't test it properly. This worked because I was in a debug
build with shared libraries. In that setup everything magically works.
A normal Release build doesn't work at all. By default libclang
doesn't export any non-libclang functions. When I remove the exports
list I get scary errors like
: CommandLine Error: Option 'debug' registered more than once!
LIBCLANG FATAL ERROR: inconsistency in registered CommandLine option
because I have two copies of clang in the same address space.