textDocument/documentSymbol request (Outline)

[Bochlin]

This pull request replaces pull request #75 textDocument/documentSymbol (Outline).

Major points:

• Support for "textDocument/documentSymbol" request according to LSP specification 3.15.
• New requests module in vhdl_ls.
• Adds source_range: SrcPos field to AST design units denoting the range in the source code for the design unit.
• New HasDocumentSymbol trait in vhdl_ls/requests/document_symbol for generating a lsp_types::DocumentSymbol.

The source range is only fully implemented for items in the list below, other items have their source range determined by the source range of their identifier.

• Primary design unit
• Secondary design unit
• Block statement
• Process statement

This pull request is big enough as it is and I believe that this provides the base line for the documentSymbol request and that the feature should be incrementally improved.

[umarcor]

FTR, if using Python is acceptable, rust_hdl might be supported as a backend of pyVHDLModel, which would allow sharing higher abstraction implementations (such as this PR) in a way agnostic to the parser. There is a GUI demo in https://umarcor.github.io/osvb/apis/project.html#usage which provides the same functionality as this PR, but a custom tkinter GUI is used instead of targeting the VSCode API.

Alternatively, a version of pyVHDLModel might be implemented in Rust, but I guess that's duplicating the effort.

Ref: Paebbels/sphinxcontrib-vhdldomain#5

[bradleyharden]

Alternatively, a version of pyVHDLModel might be implemented in Rust, but I guess that's duplicating the effort.

@umarcor, isn't pyVHDLModel basically just a VHDL AST in Python? rust_hdl already has that. Being able to convert it to Python in a standardized way would be nice though.

[Bochlin]

@umarcor It should also be noted that while the screen shot in the PR is from VS Code, there are no VS Code APIs involved as it targets the Language Server Protocol.

[umarcor]

isn't pyVHDLModel basically just a VHDL AST in Python? rust_hdl already has that. Being able to convert it to Python in a standardized way would be nice though.

@bradleyharden, essentially, yes, all of them are "a VHDL AST". However "The VHDL AST" does not exist. Each AST is tailored to the conception/needs of the tool/developer. pyGHDL.dom is precisely a bridge (conversion) between one of GHDL's ASTs and one of pyVHDLModel's ASTs. We are now using the pyVHDLModel.SyntaxModel, which is an AST for representing the sources, not the elaborated design. While doing so, we had to rethink and tweak both GHDL's AST and pyVHDLModel's AST.

Hence, the idea with rust_hdl would be the same. Instead of generating "arbitrary" bindings in Python, have them be a rust_hdl AST to pyVHDLModel.SyntaxModel conversion. However, I'm not sure about "Python bindings for rust_hdl" being a demanded feature (except for the VUnit dependency scanning we discussed).

It should also be noted that while the screen shot in the PR is from VS Code, there are no VS Code APIs involved as it targets the Language Server Protocol.

@Bochlin, correct. I was not suggesting to change this PR or implement it differently. I understand that rust_hdl <-> VSCode API is the most sensible approach here. However, I wanted to draw the attention about the GUI (user experience) similarities between the features provided by this PR and my OSVDE demo. That demo is a proof-of-concept only, not a project per se.

I am interested in using VSCode. Therefore, if the VSCode <-> LSP <-> VHDL Model/AST is done generic enough (not tailored to rust_hdl), then everything might be reused by just changing the parser. The usage of pyVHDLModel itself might be more pertinent in your other extension: https://marketplace.visualstudio.com/items?itemName=hbohlin.vunit-test-explorer.

[kraigher]

@Bochlin still want to merge this?

[Bochlin]

@Bochlin still want to merge this?

It will only provide some very basic outlining, and I will not be able to continue to improve it due to available time. Unless someone is interested in finishing the feature it is probably better to close it.