sammccall added inline comments.
================ Comment at: clang/lib/Sema/SemaCodeComplete.cpp:3785 + if (const auto *FTD = dyn_cast<FunctionTemplateDecl>(TD)) + return FTD->getTemplatedDecl()->getType().getAsString(Policy); + if (isa<TypeAliasTemplateDecl>(TD)) ---------------- kadircet wrote: > the rendering looks a little bit surprising to me `foo<arg1,arg2> -> bool > (float)` we might consider printing parameters first, e.g. > `foo<arg1,arg2>(float) -> bool`. i think this also looks more natural for the > following signature help on function parameters. Yeah. There are a few things going on here I wasn't sure how to square: 1) the "arrow" rendering is clangd-specific, and it reorders chunks by kind (moving the ResultType chunk to the end). So if we want a specific rendering in clangd we need to be able to infer it from the chunk sequence 2) the chunk sequence should make sense when rendered as text more directly. I think the current version fails this test: `bool(float) foo<arg1, arg2>`. 3) the rendering you suggest requires us to reverse the order of bool and float somehow, ideally without some fragile coupling/assumptions in clangd I think the "natural" chunk sequence is `bool` `foo<` `arg1` `,` `arg2` `>` `(float)`. The `bool` chunk is definitely ResultType. If we make `(float)` also ResultType, we know have two RT chunks we have to stick in the signature in the right place. So maybe it's best to make it `CK_Text` or `CK_Informative`. I'll give this a spin... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D116352/new/ https://reviews.llvm.org/D116352 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
