-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doesn't seem to work with simple file #2
Comments
It seems to work if run with preprocessor's argument like this: $ clang -E -xc -I ../esp-idf/components/esp_common/include/ -I ../esp-idf/components/driver/include/ ../esp-idf/components/driver/include/driver/rmt_common.h -Xclang -load -Xclang build/libcrefl.so -Xclang -plugin -Xclang crefl -Xclang -plugin-arg-crefl -Xclang -dump But obviously, it gets all the garbage from the other include files |
In fact, even running the creflcc.py script, the source of the symbol is not set in the database. Is there a way to get only the declarations that are in the input file ? Said differently, how can I filter decl by source file ? Right now, I'm getting all the functions declared in the stdlib so that's a lot of noise I'm not interested about. |
you should always get everything that is included, unless there are parse errors due to incorrect flags. there is a merge step in crefltool that combines the metadata from multiple source files and it is designed to de-duplicate common nodes but they need to be there because they are dependencies. there should be only one copy of these in the final linked binary due to the merge. but I think this may be a different problem. currently if there are errors during the parse, the plugin will continue but the AST will be incomplete and some nodes may have errors and thus not be emitted in the reflection metadata. it would be nice to see errors when invoking the plugin but I did not figure that out yet. common problems are not having the correct language (i.e. you'll notice that hope this helps. |
Ideally, each symbol in the database should refer to the source where it's declared (or defined?). That way, it could be possible to filter symbols that aren't in the current compilation unit. I think it's ok to use --cpp or -E or whatever argument to clang as long as it's matching the final API that'll likely not be compiled by clang anyway. In the preprocessor output, there are |
I'm using this file as an example for input: https://github.com/espressif/esp-idf/blob/master/components/driver/include/driver/rmt_common.h
Like this:
The functions declared in the file aren't listed in the output dump.
The text was updated successfully, but these errors were encountered: