[clang-tools-extra] [clangd] Support go-to-definition on type hints. The core part (PR #86629)

[Younan Zhang via cfe-commits]

================
@@ -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>
----------------
zyn0217 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?

Frankly, it is because the protocol requires a source range of something, and I'm concerned that providing only one source location doesn't really make a better experience. But I have to say I've never attempted it before, so I think it's worth a try.

> What vscode seems to do is call textDocument/definition at the start position of the range, and navigate to the resulting definition location.

I have realized that problem; it looks like a call to `textDocument/definition` is not cheap and it usually takes a few seconds to respond (taking us to the definition/getting the hover content) on my other large project.

> 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.)

Thanks! I really appreciate that and will explore it soon. :)

https://github.com/llvm/llvm-project/pull/86629