Problems reported for standard libraries can severely clutter important issues about rust_hdl HOT 15 CLOSED

I think we should start with the simple case and add more advanced methods as they are proven necessary. I will thus start implementing support for having a configuration file in the home folder and from an environment variable.

from rust_hdl.

I added support for config from home folder and environment variable now. You can read about it in README.md.

from rust_hdl.

Great to see improvements flying in so fast, thanks @kraigher.
Is it worth mentioning how the 'home directory' is interpreted on Windows? Or linking to the rust docs?

from rust_hdl.

You can either have full semantic analysis or only syntactic errors.
There is no technically feasible middle ground.
To ignore just errors caused by the omission of standard libraries would require knowing exactly what they contain which is equivalent with just having them built in which would eliminate the need to ignore their errors.

from rust_hdl.

What would probably help you is if there was a way to "install" the standard libraries and ieee libraries such that they are do not have to be mapped from every vhdl_ls.toml file.

Maybe vhdl_ls binary could have a command line argument to point to these libraries or read an environment variable. Thus you could set this globally in your language server configuration in the IDE and it would work.

from rust_hdl.

I agree with @GlenNicholls that it is tedious to map standard VHDL libraries such as std, ieee, osvvm, uvvm, etc. in each vhdl_ls.toml file. As the source files of these standard libraries are usually not located within the current project folder, they need to get referenced by absolute paths. These may vary among installations on different computers or different HDL simulator environments. Thus versioning these vhdl_ls.toml files becomes a headache.

It would be nice if rust_hdl could be enhanced to be able to merge several vhdl_ls.toml config files. E.g., it could consider the following hierarchy of config files:

1. /etc/rust_hdl/vhdl_ls.toml
2. ~/.vhdl_ls.toml
3. File pointed to by the environment variable $RUST_HDL_VHDL_LS_TOML
4. any vhdl_ls.toml file found recursively above the current directory of the VHDL source file
5. the vhdl_ls.toml file in the current directory

vhdl_ls.toml found later may overwrite the library mappings found in previously parsed vhdl_ls.toml files. This would enable to specify a global mapping of standard VHDL libraries, which could be overridden if needed for a specific project / EDA environment. @kraigher: What do you think? Is this approach reasonable or too complex?

@GlenNicholls: By the way, GHDL installs the VHDL sources for its standard libraries to $PREFIX/lib/ghdl/src/. I set up my vhdl_ls.toml to reference these files, and my VHDL editing experience supported by rust_hdl's language server improved considerably. Thanks @kraigher for developing this helpful tool!

from rust_hdl.

I think the idea of supporting nested vhdl_ls.toml files is good. They would be evaluated in a defined order where a library mapping or setting in an earlier configuration file is overridden by one in a later file. Note that vhdl_ls.toml contains only a library mapping today but I envision other settings to also end up there in the future.

Regarding the order proposed by @maehne I basically agree about points 1-3.

1. Installed location
2. Home folder
3. Environment variable

For points 4-5 it is important to understand that the library mapping must be consistent for the entire project. Currently vhdl ls looks for the configuration file in the initializeParams.rootUri which is the root of the workspace in the IDE. These settings are then applied to all vhdl files in the workspace. It cannot be that vhdl files in one folder have a different library mapping than those in another folder within the same "project" it does not make sense and can result ill-defined semantics in my opinion. I would thus be careful about adding 4-5 without thinking it through more.

Currently we do not have an installed location for vhdl ls so we would have to invent it. For 1 I would rather define the path as relative to the vhdl_ls executable to avoid having to create absolute paths for different operating systems.

@GlenNicholls Would this proposal solve you inconveniences?

from rust_hdl.

@kraigher: Thanks for your feedback on my proposal and refining it!

Regarding your modification to point 1, I agree with your reasoning that maybe expressing it relative to the location of the vhdl_ls executable may help with portability. However, I also think that it will easily break conventions for storing configuration files on different OS platforms. Maybe, this could be configured through some option in the build system?

Regarding points 4 to 5, I acknowledge the need for a single library mapping for all VHDL files, which will get elaborated together to form a design hierarchy. However, it may be difficult to guarantee the presence of a single vhdl_ls.toml file per project -- especially, if that project incorporates several separately developed and versioned IP cores, which, e.g., got integrated as git submodules into the project directory.

We also have to take into account the common practice to integrate all VHDL files (even from external developed IP cores) into a single work library. Therefore, it may be needed to progressively add more and more VHDL files to a library in a well defined order. Maybe files 4 to 5 should be handled more explicitly, i.e., by adding a kind of include statemement to the vhdl_ls.toml syntax. What do you think?

A separate issue is that with the advent of tools like ghdl's language server, fusesoc, vunit, hdl-make, etc. project directories fill up with configuration files that all contain similar information. A joint file format for this information or a way to automatically generate these configuration files would be nice and safe development time.

from rust_hdl.

@kraigher do you think it's feasible to also detect new and/or changed files in the config file hierarchy?

I was experimenting dumping the inferred libraries from HDL Checker in the Rust HDL config format and had to restart it so it would be picked up, I think a self refresh would be very handy!

from rust_hdl.

@suoto Yes it is probably feasible. Create a new issue for it so we do not forget about it.

from rust_hdl.

Great to see improvements flying in so fast, thanks @kraigher.
Is it worth mentioning how the 'home directory' is interpreted on Windows? Or linking to the rust docs?

Yes it could be helpful.

from rust_hdl.

@GlenNicholls Would this proposal solve you inconveniences?

Yes, this looks like it will solve my problem. I don't mind installing the libraries on my own somewhere on my system as long as theres a way to globally define that location. I'll let you know if I run into any problems with this

from rust_hdl.

@kraigher: Thanks for implementing support for configuring vhdl_ls via A ~/.vhdl_ls.toml file. In a first quick test, it works nicely for me. I see one issue with supporting configs for different language versions. It would be nice to be able to set up in ~/.vhdl_ls.toml, the available libraries in the different VHDL language versions supported by the EDA tools, i.e., nowadays primarily for VHDL-1993 and VHDL-2008. The project-wide vhdl_ls.toml would need to specify the language version and vhdl_ls would choose the set of libraries from ~/.vhdl_ls.toml, which is "closest", i.e. less than or equal, to the specified language version in vhdl_ls.toml.

from rust_hdl.

The current focus is to support VHDL 2008.
There is no standard switch to select 1993 today. I think editing 1993 code with 2008 language server still provides value compared to nothing. I do not rule it out in the future but it is not a priority today.

from rust_hdl.

I assume the implemented solution resolves this issue.

from rust_hdl.