[PATCH] D59639: [clangd] Print template arguments helper

Eric Liu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Mar 21 10:35:12 PDT 2019


ioeric added inline comments.


================
Comment at: clang-tools-extra/clangd/AST.cpp:88
 static const TemplateArgumentList *
 getTemplateSpecializationArgs(const NamedDecl &ND) {
   if (auto *Func = llvm::dyn_cast<FunctionDecl>(&ND))
----------------
can we unify this with `getTemplateSpecializationArgLocs` somehow? 

it seems that args as written would also be favorable here (see FIXME in line 112)


================
Comment at: clang-tools-extra/clangd/AST.cpp:131
+  PrintingPolicy Policy(ND.getASTContext().getLangOpts());
+  if (auto Args = getTemplateSpecializationArgLocs(ND))
+    printTemplateArgumentList(OS, *Args, Policy);
----------------
Eugene.Zelenko wrote:
> Return type is not obvious, so auto should not be used.
nit: I'd suggest keeping `{}` for symmetry.


================
Comment at: clang-tools-extra/clangd/AST.cpp:133
+    printTemplateArgumentList(OS, *Args, Policy);
+  else if (auto *Cls = llvm::dyn_cast<ClassTemplateSpecializationDecl>(&ND)) {
+    if (const TypeSourceInfo *TSI = Cls->getTypeAsWritten()) {
----------------
why isn't this handled in `getTemplateSpecializationArgLocs`? Add a comment?


================
Comment at: clang-tools-extra/clangd/AST.cpp:134
+  else if (auto *Cls = llvm::dyn_cast<ClassTemplateSpecializationDecl>(&ND)) {
+    if (const TypeSourceInfo *TSI = Cls->getTypeAsWritten()) {
+      auto STL = TSI->getTypeLoc().getAs<TemplateSpecializationTypeLoc>();
----------------
could you add comment/example explaining what's special about this case?


================
Comment at: clang-tools-extra/clangd/AST.h:54
+/// Returns an empty string if type is not a template specialization.
+std::string printTemplateArgsAsWritten(const NamedDecl &ND);
+
----------------
Maybe `printTemplateSpecializationArgs` since we are only handling template specialization? 

I think we could drop `AsWritten` from the name. It should be clear to just explain in the comment.  


================
Comment at: clang-tools-extra/unittests/clangd/ASTUtilsTests.cpp:16
+
+TEST(ASTUtils, PrintTemplateArgs) {
+  Annotations Test(R"cpp(
----------------
I think this kind of tests would be more readable using `TEST_P` [1] with code and expected arguments as parameters.

Up to you though.

[1] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#specifying-names-for-value-parameterized-test-parameters


================
Comment at: clang/lib/AST/TypePrinter.cpp:1635
 
+static void printArgument(const TemplateArgument &A, const PrintingPolicy &PP,
+                          llvm::raw_ostream &OS) {
----------------
could you add clang tests for these changes?


================
Comment at: clang/lib/AST/TypePrinter.cpp:1643
+  const auto &Kind = A.getArgument().getKind();
+  assert(Kind != TemplateArgument::Null &&
+         "TemplateArgumentKind can not be null!");
----------------
why? 

```
    /// Represents an empty template argument, e.g., one that has not
    /// been deduced.
```
It seems legitimate. 

Since this hot code path, we would want to avoid hard assertion if possible.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59639/new/

https://reviews.llvm.org/D59639





More information about the cfe-commits mailing list