================
@@ -1637,6 +1678,144 @@ TEST(TypeHints, SubstTemplateParameterAliases) {
ExpectedHint{": static_vector<int>", "vector_name"});
}
+template <typename... Labels>
+void assertTypeLinkHints(StringRef Code, StringRef HintRange,
+ Labels... ExpectedLabels) {
+ Annotations Source(Code);
+ auto HintAt = [&](llvm::ArrayRef<InlayHint> InlayHints,
+ llvm::StringRef Range) {
+ auto *Hint = llvm::find_if(InlayHints, [&](const InlayHint &InlayHint) {
+ return InlayHint.range == Source.range(Range);
+ });
+ assert(Hint && "No range was found");
+ return llvm::ArrayRef(Hint->label);
+ };
+
+ TestTU TU = TestTU::withCode(Source.code());
+ TU.ExtraArgs.push_back("-std=c++2c");
+ auto AST = TU.build();
+
+ Config C;
+ C.InlayHints.TypeNameLimit = 0;
+ WithContextValue WithCfg(Config::Key, std::move(C));
+
+ auto Hints = hintsOfKind(AST, InlayHintKind::Type);
+ EXPECT_THAT(HintAt(Hints, HintRange),
+ ElementsAre(HintLabelPieceMatcher(ExpectedLabels, Source)...));
+}
+
+TEST(TypeHints, Links) {
+ StringRef Source(R"cpp(
+ $Package[[template <class T, class U>
----------------
HighCommander4 wrote:
Is there a reason to prefer putting full decl source ranges into
`InlayHintLabelPart.location`, rather than single-token source ranges (e.g.
just the range `Package`) like in the go-to-definition response?
What vscode seems to do is call `textDocument/definition` at the start position
of the range, and navigate to the resulting definition location.
I guess most of the time that works either with a full source range or a
single-token source range as input, but I think a single-token source range
might be more robust (less chance for edge cases where the first token of the
full source range is claimed by some descendant node, and also less chance for
edge cases where the full source range spans macro expansion boundaries).
We have [some
utilities](https://searchfox.org/llvm/rev/1664610130b88ef168e33eddfe973a3f11bd4261/clang-tools-extra/clangd/XRefs.cpp#414-415)
for getting the single-token source range for the go-to-def response, which we
could probably reuse.
(As a bonus, it makes the tests a bit easier to write and read.)
https://github.com/llvm/llvm-project/pull/86629
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
