Add better linter support

[GlenNicholls]

I have been trying to use GHDL as the linter and one of the problems I run into is it cannot find libraries, so it fails to analyze files. I know having a project file is in the road-map, I'm just adding an issue to track it.

Currently, here is my opinion about language server options for VHDL:

GHDL LS

This is a decent tool and I have used it, but I don't really like it a whole lot as a language server. IMO, I think an IDE should have a lightweight tool for linting purposes that is easily downloaded via the VS code extension marketplace. GHDL can be a huge pain to install in certain situations and requires the user to jump through a lot of hoops. Using GHDL LS as the language server doesn't really make sense because you would have to document how to install GHDL, any dependencies needed, and debug steps for Windows, Linux, and Mac. When using things like MSYS, docker, WSL, etc., it becomes a huge pain for the user to track where things break especially when people have to deal with Python and other system requirements unrelated to HDL development. It's a neat tool that has been very well maintained, but I just don't feel that the GHDL language server is the right tool for the job.

Rust HDL

I have been using the Rust HDL VSC language server (VSC extension of Rust HDL) for about a year now and it is very lightweight and fast. For analysis, nearly all of VHDL 2008 is supported. The biggest flaw with the two tools at this point is the VSC extension is not actively maintained. The maintainer is still active, but bug fixes and open issues take a while to get fixed. As for RustHDL, it is still maintained by the creator, but the biggest limitation is he is looking to mentor people into contributing as his time is extremely limited and he no longer writes VHDL at work. Currently, RustHDL doesn't support semantic analysis, so it has some limitations with respect to the go-to definition of overloaded subprograms and other small things that synthesis tools complain about during elaboration. GHDL on the other hand does support this though. It works very nicely for syntax analysis and go-to definition of components and such. It was designed to recover from code errors which are ideal for a linter. GHDL doesn't crash (unless there's a bug), but it doesn't continue the analysis of a file after the first major error as outlined at the beginning of this ticket.

The largest advantage of RustHDL over GHDL is that it is written in Rust and not Ada. Rust is extremely fast, memory safe, and I personally feel that it is easier to read which would attract a larger audience to contribute. By adopting RustHDL as the underlying LS, it would already have the notion of a project which would satisfy this ticket, although it might require work on your end to fix issues as they pop up. The other advantage I see is the infrastructure in RustHDL is already there, so semantic analysis would just require someone with time to be mentored by Kraigher to add that support. The other nice aspect of RustHDL is the creators' vision, as noted by the name, was to eventually support Verilog/SV as well which would mean a single linting tool for the extension, and the user wouldn't be required to configure the settings for a simulator.

[qarlosalberto]

Really nice explanation!! I think that the best option is RustHDL, it's easier for the user.
I need to think how we can let to the user to choose between RustHDL or a simulator (GHDL, ModelSim...) as linter.

[umarcor]

FTR, hdl_checker (/cc @suoto) wraps several tools (GHDL, ModelSim, Vidado) for providing LSP features. It might be interesting to:

1. Add rust_hdl to hdl_checker.
2. Use hdl_checker in TerosHDL, instead of handling LSP tools directly (/cc @suzizecat).
3. Let people in Verible know about hdl_checker (/cc @mithro).

[qarlosalberto]

I'm going to do a summary of the current TerosHDL features:

• Liner (ModelSim, Vivado, Verilator, GHDL, Verible, Icarus).
• Go to definition in the current file (ctags).
• FSM extractor (tree-sitter-vhdl, tree-sitter-verilog).
• Documenation extractor (tree-sitter-vhdl, tree-sitter-verilog).
• Formatter (iStyle, Verible and others).

Missing features:

• Complete SV parser. (surelog?)
• Go to definition between files. (RustHDL?)
• Merge all the features in a LSP? (hdlChecker?)

[GlenNicholls]

@umarcor I like the idea of using hdl_checker as the single interface for TerosHDL. Adding that support to hdl_checker would make it really easy for the user to change LS on the fly, but the user also wouldn't need to worry about the syntax highlighting and snippets changing while changing the underlying tool.

[GlenNicholls]

@qarlosalberto

Go to definition between files. (RustHDL?)

I believe GHDL LS supports this, although it's been a while since I last used it.

[umarcor]

GHDL does support it: ghdl/ghdl-language-server#11. There you have an example hdl-prj.json file for having 'Go to definition' in one of the VUnit examples (which finds all VUnit libs).

[qarlosalberto]

Yes, but I think it's better to choose RustHDL because we can embed a compiled version (Windows, Linux, Mac) in TerosHDL. It's easy to add RustHDL to TerosHDL project manager ( https://terostechnology.github.io/terosHDLdoc/features/project_manager.html) We only need to do a conversor from TerosHDL project file to RustHDL project file. El mar., 30 mar. 2021 22:05, Unai Martinez-Corral ***@***.***> escribió:

…

GHDL does support it: ghdl/ghdl-language-server#11 <ghdl/ghdl-language-server#11>. There you have an example hdl-prj.json file for having 'Go to definition' in one of the VUnit examples (which finds all VUnit libs). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#99 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNN4R3JFFQUQ5N5TSNP7ETTGIVJXANCNFSM4Z33YJRA> .

[umarcor]

Agree. It was just a clarification/confirmation.

[GlenNicholls]

@qarlosalberto regarding the project file, can you reference https://github.com/Bochlin/rust_hdl_vscode#configuration when you guys implement rust_hdl or GHDL ls for the TerosHDL project file? The format to me doesn't really matter since I can update my Python code to quickly implement it. I really like the way that extension searches for the project file in the following precedence:

vhdl_ls will load configuration files in the following order of priority (first to last):

1. A file named .vhdl_ls.toml in the user home folder.
2. A file name from the VHDL_LS_CONFIG environment variable.
3. A file named vhdl_ls.toml in the workspace root.

I use option 3. I have a script that generates the project file in the root of the repository so it is ready for the user when they perform a checkout, so all they do is open VS code in the root of the repo they checkout. Having the ability to select and add files to a library in the UI is nice for quick changes to test, but not ergonomic for large projects.

[qarlosalberto]

@GlenNicholls could I close this issue with the recent added of RustHDL? We could continue in other issues.

[GlenNicholls]

@qarlosalberto That is fine with me!