feat(lsp): Implement textDocument/documentSymbol

[jeanp413]

I've implemented the case when the response is a hierarchy of symbols DocumentSymbol[] (same as TypeScriptDocumentSymbolProvider in vscode).
Let me know if I should also implement the case when the response is a flat list of all symbols SymbolInformation[].

Related #8643

[jeanp413]

Not sure what if condition this linting error is referring to, any ideas? ...

Fixed the linting error

[kitsonk]

Looks good... let's try to remove the allow deprecated though, I think I have a solution.

[kitsonk]

LGTM

[kitsonk]

I am getting LSP panics (though I can't see what they are) with this commit. I am trying to narrow it down, but if I can't easily find it, we will need to revert this PR.

[kitsonk]

Actually I think it is #9664, as I was using a debug build and when I created a test case to reproduce it, I was getting:

process didn't exit successfully: `/Users/kitsonk/github/deno/target/debug/deps/deno-73d82b9ef03210f0 'lsp::language_server::tests::test_document_symbol_with_imports' --exact --nocapture` (signal: 11, SIGSEGV: invalid memory reference)

I did a release build and it went away.

[jeanp413]

Actually I think it is #9664,
I did a release build and it went away.

In my case I'm on ubuntu 20.10 and haven't encounter any error so far, either way, let me know if something goes wrong

[kitsonk]

In my case I'm on ubuntu 20.10 and haven't encounter any error so far, either way, let me know if something goes wrong

It is something that only affects certain Intel debug builds when you try to access ICU data within JavaScript. tsc has a few code paths that uses the ICU data (the Intl APIs use it) and when you hit one of those it blows up. It has to do with duplicate symbols introduced with WebGPU. It is very obscure. Nothing is wrong with the code.