DirectXShaderCompiler
DirectXShaderCompiler copied to clipboard
IDxcCursor does not support template parameter and template argument querying
Upstream libclang provides CXCursor functionality to query template parameters and template arguments using clang_Cursor_getNumTemplateArguments, clang_Cursor_getTemplateArgumentKind, clang_Cursor_getTemplateArgumentUnsignedValue and clang_Cursor_getTemplateArgumentValue. (see for example, https://clang.llvm.org/doxygen/group__CINDEX__TYPES.html#ga08dac49044448c022457224e73223eb2).
Until Sept 2022, the functionality above was restricted in libclang to function templates but this was since extended to include class templates and partial specializations. This is the CR in question: https://reviews.llvm.org/D134416.
I made a modest attempt at porting these changes and extending the IDxcCursor interface, but I noticed that the cursor kinds itself doesn't match what I expect so I suspect that the synthesized AST node types have diverged somewhat from upstream LLVM.
To get a sense for the current AST structure, I parsed the following test code:
template <typename A, int B, uint C> class Foo {};
Foo<float, -2, 3> foo;
Dumping the contents of the AST with some formatting applied produces this:
source.hlsl ((TranslationUnit) TranslationUnit source.hlsl) [0:0] : [0, 73)
Foo ((Declaration) ClassTemplate Foo<A, B, C>) [1:44] : [0, 49)
A ((Declaration) TemplateTypeParameter A) [1:20] : [10, 20)
B ((Declaration) NonTypeTemplateParameter B) [1:27] : [22, 27)
C ((Declaration) NonTypeTemplateParameter C) [1:35] : [29, 35)
uint ((Reference) TypeRef uint) [1:30] : [29, 33)
foo ((Declaration) VarDecl foo) [2:19] : [51, 72)
Foo ((Reference) TemplateRef Foo) [2:1] : [51, 54)
((Expression | Unexposed) UnexposedExpr) [2:12] : [62, 64)
((Expression) UnaryOperator) [2:12] : [62, 64)
((Expression) IntegerLiteral) [2:13] : [63, 64)
((Expression | Unexposed) UnexposedExpr) [2:16] : [66, 67)
((Expression) IntegerLiteral) [2:16] : [66, 67)
Note in line 3, Foo is recognized as a DxcCursor_TemplateRef kind but it has two children referring to the integer literals used as the 2nd and 3rd template arguments. As a result, there doesn't seem to be a way to recover types passed as template arguments at the moment.
To set expectations here, I think we're pretty unlikely to prioritize this. Our long-term goal is to move away from the IDxcCursor interface entirely in favor of LSP-based tooling provided by upstream.
We would accept patches to this area, but we're not likely to do any work here.