[PATCH] D89277: [clangd] Add $/dumpMemoryTree LSP extension

Sam McCall via cfe-commits cfe-commits at lists.llvm.org
Wed Oct 14 14:47:02 PDT 2020


On Wed, Oct 14, 2020 at 6:10 PM Kadir Cetinkaya via Phabricator <
reviews at reviews.llvm.org> wrote:

> kadircet added a comment.
>
> In D89277#2329947 <https://reviews.llvm.org/D89277#2329947>, @sammccall
> wrote:
>
> > (sorry out today and haven't looked at code yet)
>
> no worries it is a prototype, I wouldn't spend time looking at the
> implementation until we agree on the interaction :D
> OTHO, checking out the lit test for output would probably be useful.
>
> > If it's a custom method, I think it should return the data as a json
> structure - the client already has to have custom support to invoke it,
> displaying the result isn't much extra work.
>
> SGTM. WDYT about a json object in the form of:
>
>   interface MemoryTreeNode {
>     name: string;
>     totalSize: int;
>
I'd also include self-size.


>     children?: Node[];
>   };
>
This looks like:
{
  "name": "root"
  "totalSize": 100,
  "children": [
    {
      "name": "component1",
      "totalSize": 25,
    },
    {
      "name": "component2",
      "totalSize": 75,
    }
  ]
}

A couple of alternatives: I think making "children" an object and moving
the name up to the edge is more natural.
We no longer name the root, which I don't think is a bad thing.
{
  "totalSize": 100,
  "children": {
    "component1": {
      "totalSize": 25,
    },
    "component2": {
      "totalSize": 75,
    }
  ]
}

A more-compact alternative folds the child attributes into the node itself.
This is probably more awkward to query directly (e.g. "does a node have
children") and might end up being marshalled into a struct.
On the other hand, I think it's easier to read directly e.g. in logs, esp
when deeply nested.
{
  "_total": 100,
  "component1": {
    "_total": 25
  }
  "component2": {
    "_total": 25
  }
}

> And I would really love to add a tree view to vscode, I think it wouldn't
> be hard (vs call hierarchy: no laziness and no direction-flipping) and
> could be reused for an AST viewer.
>
> right, vscode already has APIs for it,
> https://code.visualstudio.com/api/extension-guides/tree-view.
>
I found some time today and have a prototype of AST dump... nearly working
:-)
The complexity of the treeview API does indeed mostly disappear when you
have simple tree-shaped data and it's all available at once.
Just the annoying extension-point boilerplate remains...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20201014/ed400772/attachment-0001.html>


More information about the cfe-commits mailing list