libclang support for Matchers

I’m looking to add support for matchers using the “C” API and Python bindings.

I have started doing some initial work to add support for this:
https://github.com/ReDucTor/clang/commit/d367e9ab34668da6341307765c303fbbd1b673e3

It would be good to get any advice/suggestions relating to these changes I’m still getting familiar with the related APIs and coding standards.

I’m looking to add support for matchers using the “C” API and Python bindings.

I have started doing some initial work to add support for this:
https://github.com/ReDucTor/clang/commit/d367e9ab34668da6341307765c303fbbd1b673e3

It would be good to get any advice/suggestions relating to these changes I’m still getting familiar with the related APIs and coding standards.

If you find it useful, it seems like a small directed patch that makes sense :slight_smile:

Does the marchers API offer the stability that libclang tries to provide?
If not, exposing marchers will be tough

Does the marchers API offer the stability that libclang tries to provide?
If not, exposing marchers will be tough

As the dynamic matchers use strings, what stability concerns do you have?

Does the marchers API offer the stability that libclang tries to provide?
If not, exposing marchers will be tough

As the dynamic matchers use strings, what stability concerns do you have?

Will the supported strings be stable?

For the usage of strings clang already has and is recommended to use of clang-query which supports the same strings.

This would just be moving it from a command line interface to a C API.

I am open to other alternatives if anyone has some.

For the usage of strings clang already has and is recommended to use of clang-query which supports the same strings.

This would just be moving it from a command line interface to a C API.

I am open to other alternatives if anyone has some.

I have no better suggestion and think that this would be very useful.

Does the marchers API offer the stability that libclang tries to provide?
If not, exposing marchers will be tough

As the dynamic matchers use strings, what stability concerns do you have?

Will the supported strings be stable?

Reasonably so, but not libclang C API style backwards compatible forever. The question is how much that matters to libclang users (I honestly have no idea). C API stability seems to be obviously more important, as it can just crash a program. The worst thing with a wrong string here is that you’ll get an error back.