This initial definition handles the commands, options, matchers, literal values, etc. used in a file that can be interpreted by clang-query. When using clang-query as an interpreter, this syntax highlighting would be helpful.
Diff Detail
Diff Detail
Event Timeline
Comment Actions
Matchers change over time, so it may be wise to create a script to parse clang/lib/ASTMatchers/Dynamic/Registry.cpp and extract the matcher definitions from there. Save manually updating of this.
Comment Actions
I also have considered adding a script to automatically generate this file. But where to store the output?
I am just thinking about adding llvm/utils/vim/syntax/clang-query.vim to gitignore, and adding a script to generate the file every time when llvm is built. Could that be a good solution? What do you think?
Comment Actions
Don't know too much about it, but it looks plausible enough and should be pretty harmless, so might as well go in.
| llvm/utils/vim/ftdetect/clang-query.vim | ||
|---|---|---|
| 1 | Is there precedent for this file extension? Any concerns about what it might overlap with? | |
| llvm/utils/vim/syntax/clang-query.vim | ||
| 492 | Guess there's no chance of generating this list from some other existing source-of-truth? | |
Comment Actions
I wrote this demo script to extract the matchers from the file clang/lib/ASTMatchers/Dynamic/Registry.cpp as you mentioned. However, there are still some missing matchers (fixedPointLiteral, hasAnyBody, templateArgumentLoc and traverse) in addition to the two matchers (findAll and equalsNode) that are mentioned to be missing in the comments of function RegistryMaps::RegistryMaps. I am not very sure whether the comment mentioned all of the missing matchers, or I missed some registries other places in this file.
My list of matchers is extracted from the file clang/docs/LibASTMatchersReference.html through the following commands.
pandoc clang/docs/LibASTMatchersReference.html -t markdown - | grep '^\[\(.*\)\]{#.*}' | sed 's/\[\(.*\)]{#.*\}/\1/g' | sort | uniqAnd the list generated with the commands above seems more reliable. However, this solution requires pandoc, maybe the specific version of mine, and it cannot automatically update the syntax file.
Therefore, I suggest we just add this syntax file and ask other developers to update the HTML document together with the syntax file manually. If we really need such a syntax definition. Or, I can still create a stand-alone repo to provide this syntax file as a plugin.
And just as what has been mentioned by @dblaikie, the extension name also needs to be determined. The`*.cq` name is what I am using. If you have other suggestions, I will update that.
Thanks for the suggestions.
| llvm/utils/vim/ftdetect/clang-query.vim | ||
|---|---|---|
| 1 | No, there isn't. The test case of clang-query uses *.script (e.g. clang-tools-extra/test/clang-query/Inputs/foo.script), but it seems not good enough. The *.cq is what I am using. | |
| llvm/utils/vim/syntax/clang-query.vim | ||
| 492 | This list was generated from clang/docs/LibASTMatchersReference.html :-) | |
| llvm/utils/vim/syntax/clang-query.vim | ||
|---|---|---|
| 492 | Oh, I meant automatically so it'd stay in sync. But guess not - maybe at some point we'll eventually move the matchers to some tablegen files - to generate documentation and the source code, etc. | |
Comment Actions
The Registry is the truth about what clang-query can accept. Any matcher not registered in there won't work with clang-query. I've rustled up a patch, D98556, to include fixedPointLiteral, hasAnyBody and templateArgumentLoc in there.
traverse needs a little work to get working, equalsNode makes no sense in clang-query. I'm not sure of the exact issue with findAll.
Is there precedent for this file extension? Any concerns about what it might overlap with?