[llvm-branch-commits] [clang-tools-extra] [clang-doc] add namespaces to JSON generator (PR #143209)

[Erick Velez via llvm-branch-commits]

================
@@ -171,5 +171,78 @@ TEST(JSONGeneratorTest, emitRecordJSON) {
 })raw";
   EXPECT_EQ(Expected, Actual.str());
 }
+
+TEST(JSONGeneratorTest, emitNamespaceJSON) {
+  NamespaceInfo I;
+  I.Name = "Namespace";
+  I.Path = "path/to/A";
+  I.Namespace.emplace_back(EmptySID, "A", InfoType::IT_namespace);
+
+  I.Children.Namespaces.emplace_back(
+      EmptySID, "ChildNamespace", InfoType::IT_namespace,
+      "path::to::A::Namespace::ChildNamespace", "path/to/A/Namespace");
+  I.Children.Records.emplace_back(EmptySID, "ChildStruct", InfoType::IT_record,
+                                  "path::to::A::Namespace::ChildStruct",
+                                  "path/to/A/Namespace");
+  I.Children.Functions.emplace_back();
+  I.Children.Functions.back().Name = "OneFunction";
+  I.Children.Functions.back().Access = AccessSpecifier::AS_none;
+  I.Children.Enums.emplace_back();
+  I.Children.Enums.back().Name = "OneEnum";
+
+  auto G = getJSONGenerator();
+  assert(G);
+  std::string Buffer;
+  llvm::raw_string_ostream Actual(Buffer);
+  auto Err = G->generateDocForInfo(&I, Actual, ClangDocContext());
+  assert(!Err);
+  std::string Expected = R"raw({
+  "Enums": [
+    {
+      "Name": "OneEnum",
+      "Scoped": false,
+      "USR": "0000000000000000000000000000000000000000"
+    }
+  ],
+  "Functions": [
+    {
+      "IsStatic": false,
+      "Name": "OneFunction",
+      "ReturnType": {
+        "IsBuiltIn": false,
+        "IsTemplate": false,
+        "Name": "",
+        "QualName": "",
+        "USR": "0000000000000000000000000000000000000000"
+      },
+      "USR": "0000000000000000000000000000000000000000"
+    }
+  ],
+  "Name": "Namespace",
+  "Namespace": [
+    "A"
+  ],
+  "NamespacePath": "path/to/A/Namespace",
----------------
evelez7 wrote:

I've been trying to figure this out and I am inclined to remove this field altogether (in fact I have the changes staged right now). I copied the Mustache behavior from here: 

https://github.com/llvm/llvm-project/blob/4e6896244f4129a22e311f7f6290a595b6f03b75/clang-tools-extra/clang-doc/HTMLMustacheGenerator.cpp#L473-L475

And I use this behavior in the initial JSON generator patch as well because Mustache does it for all entities:

https://github.com/llvm/llvm-project/blob/b567c6cc7c80ca567bf664ded8ead0a744813e52/clang-tools-extra/clang-doc/JSONGenerator.cpp#L201-L203

I think this behavior is **incorrect** for the JSON generator and a mistake on my part. References already have their own Path fields and I think that's what should be emitted, not a relative file path for linking documents. If the JSON ends up being fed to an HTML generator, then I think the HTML generator should construct its own paths for linking. @ilovepi

It was also incorrect because instead of checking for the proper `path/to/A/r`, the test was emitting checking for the filename link (something like `../index.json`) which was again an oversight by me.

As for Windows, yes it's particularly nasty for unit tests because I can't use the nice regex stuff (`{{[.*]}}` in there, so I'm figuring that out. I don't know how YAML solved it. 

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