================
@@ -5431,6 +5431,23 @@ TEST(Hover, HLSLRegisterAttributeRange) {
}
}
+TEST(Hover, HLSLRootSignature) {
+ Annotations T(
+ R"hlsl(
+ #define RS_CBV "CBV(b0)"
+ [^RootSignature(RS_CBV)]
+ void main() {}
+ )hlsl",
+ Annotations::Markers().setRangeBegin("{{").setRangeEnd("}}"));
+
+ TestTU TU = TestTU::withCode(T.code());
+ configureHLSL(TU);
+ auto AST = TU.build();
+ auto H = getHover(AST, T.point(), format::getLLVMStyle(), nullptr);
+ ASSERT_TRUE(H) << "Hover should have been returned for RootSignature!";
+ EXPECT_EQ(H->Name, "RootSignature");
----------------
mafeguimaraes wrote:
Good questions, let me clarify both.
On the first point: the patch doesn't clear `Definition`, it just never sets
it. `HoverInfo` starts empty, so `Name` and `Documentation` are populated (as
before) and `Definition` simply stays unset for this attribute. So nothing
about `Name`/`Documentation` changes.
On filling `Definition` with something meaningful instead of leaving it empty:
I looked into this before choosing this approach.
`RootSignatureAttr::getSignatureDecl()` does give us an
`HLSLRootSignatureDecl*` with the fully parsed `RootElement`s (DescriptorTable,
RootConstants, RootDescriptor, StaticSampler, etc.), so the information is
there. The only existing printer for `RootElement` is its `operator<<` (used by
`dumpRootElements()` for `-ast-dump`), and I prototyped calling it from hover
via a small `getPrintedRootSignature()` helper. It works, but the output
includes every field of every element, including defaulted ones
(`numDescriptors = 1, space = 0, ...`), which is fine for `-ast-dump` but too
verbose for a hover tooltip.
A compact hover-appropriate formatter (something like `SRV(t0), UAV(u0),
DescriptorTable(2 clauses)`) is doable, but it means visiting each
`RootElement` variant and deciding which fields matter for a quick-glance
summary, a separate, non-trivial piece of work. Given the timeline of GSoC, I'd
rather ship this suppress-and-show-docs fix now and file a follow-up issue to
build the proper reconstruction. Happy to open that tracking issue right away
if that sounds reasonable, or to scope it into this PR if you'd prefer it done
now.
https://github.com/llvm/llvm-project/pull/214955
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
