Which language servers have used slang as engine?

[scutwengxinqian]

Which language servers have used slang as engine?
I find one: https://github.com/vivekmalneedi/veridian
Are there others?

[likeamahoney]

Previously in slang discussions a new language service which is based on slang was presented.

[suzizecat]

I am working on one, with fairly good results as long as you stay in "design" SystemVerilog (UVM is an absolute nigthmare). You may check it out here and you'll get the corresponding VSCode extension there.

[Ciprian167]

@suzizecat glad to see someone is working on this.

I'm wondering what makes it a nightmare for UVM? Is slang not able to fully parse UVM testbenches or something else?

I would be interested in contributing, but I need to understand the limitations.

[suzizecat]

The issues does not really comes from slang (which handles UVM quite well as far as I can tell) but from my implementation of the LS. In particular, my base assumption is that you have one or more designs in your workspace and one design have one top level with everything ultimately nested in the scope of this top level, like a tree.

UVM kind of break this by exporting a ton of element in a package and/or directly without scope (to in the global space).

That aside, the various points that I found (from the top of my head):

• UVM uses classes (which I had not really accounted for, but should not really be an issue)
• UVM massively uses macros everywhere, which is a bit more challenging to handle with slang, as the CST/AST you get from a source code analysis will be post-preprocessing. So if you want to have the macro itself as a symbol (like you'd have for any functions) it's tricky to get back the originating tokens (see Source file lookup, macros (and UVM) #1106 ) .
• UVM "exports" a lot of functions and classes through a package, which was not expected in my initial structure of LSP backend.
• UVM is HUGE

Therefore, it makes looking up the symbols and building the index fairly challenging.
As of today, I am concentrating my efforts on reworking the "project management" aspect of things in both the LS and the VS Code extension, so I dropped a bit behind on the UVM/Verification stuff.

TL;DR : the structure I assumed for indexing data is not appropriate for UVM that have "global" symbols, macros and classes.

[Ciprian167]

Thank you for the response.

UVM massively uses macros everywhere, which is a bit more challenging to handle with slang, as the CST/AST you get from a source code analysis will be post-preprocessing. So if you want to have the macro itself as a symbol (like you'd have for any functions) it's tricky to get back the originating tokens (see #1106 ) .

I think commercial tools suffers from a similar "problem". They doesn't treat the macro itself as a symbol, and reports compilation errors from withing the macro to the same line, which make sense. I guess we would have to treat the macro as a symbol when it comes to auto completion, right?

I'll take a look into the LS implementation to understand it.

[suzizecat]

There is three main features requiring the detection of the macro (and its call) as a symbol:

• Auto complete (even though this is not what bother me the most)
• Go to definition (again, more annoying but not really problematic)
• Rename (that one is more tricky, because you need to be sure that you have all references of the symbol you are renaming. The issue here would be when you rename an element that is passed as a parameter of a macro)

Feel free to open a discussion in https://github.com/suzizecat/slang-lsp-tools/discussions so we avoid polluting this thread too much 🙂