textDocument/documentSymbol seems to ignore identical symbols

[rcjsuen]

My language server properly displays two symbols with the same name in VS Code but only one is displayed in Atom.

[
  {
    "name": "FROM",
    "location": {
      "uri": "...",
      "range": {
        "start": {
          "line": 0,
          "character": 0
        },
        "end": {
          "line": 0,
          "character": 4
        }
      }
    },
    "kind": 12
  },
  {
    "name": "RUN",
    "location": {
      "uri": "...",
      "range": {
        "start": {
          "line": 1,
          "character": 0
        },
        "end": {
          "line": 1,
          "character": 3
        }
      }
    },
    "kind": 12
  },
  {
    "name": "RUN",
    "location": {
      "uri": "...",
      "range": {
        "start": {
          "line": 2,
          "character": 0
        },
        "end": {
          "line": 2,
          "character": 3
        }
      }
    },
    "kind": 12
  }
]

[damieng]

This is a side-effect of our conversion into a tree structure. Each item has a "containerName" which in the case of multiple items with the same name is ambiguous.

Not sure what the best approach is here. The protocol is quite weak when it comes to documentSymbols and the tree structure.

[rcjsuen]

Mm, yes, it returns an array but the way the JSON is setup implies that it should be a tree... :(

See also Microsoft/language-server-protocol#112 and Microsoft/language-server-protocol#132.

[ljw1004]

@damieng even so, I think an algorithm which collapses two nodes into one doesn't seem right? is that's what happening?

Here's the Nuclide implementation: https://github.com/facebook/nuclide/blob/master/pkg/nuclide-vscode-language-service-rpc/lib/LspLanguageService.js#L1418

The Nuclide algorithm would see that all three items don't specify their parent containerName, so it'd pick the root "" to be their parent, and it'd make all three of them be children of that parent. It has the property that nodes are never coalesced. The ambiguity you mention around containerName only has the effect of sometimes not picking the right parent, and that only in the specific case of duplicate containerNames where positional information alone isn't enough to disambiguate.