[Issue] No primary unit 'INST_NAME' within library 'work'

[pidgeon777]

In my source files, instances are declared the following way:

MUX_INST : entity work.MUX_1_NBIT
port map(
  DATA_0   => data_in_0,
  DATA_1   => data_in_1,
  SELECTOR => selector_in,
  RESULT   => data_out
);

thus, using the INST_NAME: entity work.ENTITY_NAME syntax.

I'm testing the latest vhdl_ls binary (available from artifacts), and now all of my source files present the following error:

No primary unit 'MUX_INST' within library 'work'

In the previous version of vhdl_ls, the error was not present.

Still, other VHDL LSP I'm currently using (GHDL LS for example) are not presenting this error.

Is there a way to disable this behaviour? For example, by adding an option to the executable, or to the project configuration file?

Otherwise, it would be a huge problem to update all of the source files defining a different library name when instancing entities, just to reflect vhdl_ls new behaviour.

Also, compilation scripts would have to be updated, to compile the source files into the new library, breaking the compilation of the project.

I personally think that adding an option to the vhdl_ls executable or to the project configuration file would be the best solution, as it would allow the user to enable or disable this newly introduced behaviour.

[Lukas Scheller]

Can you provide more details or a minimal reproducible example? Such errors should never occur if there actually is an entity named MUX_1_NBIT. Unfortunately, I was not able to produce the error.

Something that changed, which might be the cause of the diagnostic, is that work is no longer a valid library name in your vhdl_ls.toml, i.e., you cannot write

[libraries]
[work.files] = ["file.vhd", ...]

This is because work is not a valid library name in VHDL. If you just want to 'package' all your files into one big library, you should give it some arbitrary name that does not conflict with other libraries (and that is not work). For example, I use defaultlib for this purpose.

[pidgeon777]

This is because work is not a valid library name in VHDL. If you just want to 'package' all your files into one big library, you should give it some arbitrary name that does not conflict with other libraries (and that is not work). For example, I use defaultlib for this purpose.

You were right. I did as you suggested, and problem disappeared. Now it is working as before.

So, I just edited my vhdl_ls.toml file, defining all of my non IEEE-files into a workLib library (before it was work), and this solved the issue.

Now, I can still have all of my entity instantiations in this form in my VHDL code:

INSTANCE_NAME: entity work.ENTITY_NAME

Just one thing intrigues me, the fact that my instantiations are referencing a work library, while the vhdl_ls settings file considers all of those entities to be "compiled" into a workLib library instead.

So, there is a kind of misalignment here.

[Lukas Scheller]

Yea, I understand the misalignment; this confused me at first too. The reason for this misalignment is to be found deep in the VHDL standard. In fact, the work library is just a placeholder for the current library. Whenever you type "work", at the point of compilation, that name will be replaced by the actual libraries name. I have some ideas on why the behavior is this way but note that the following is not backed by any research. I think that in the years that VHDL was developed, which were the early years of programming languages in general, Compilers worked by giving them a bunch of files and telling them "compile these files into some library named xyz". One potential advantage of that approach is that code could be reused and generic, small snippets can be compiled into any other library and distributed. Basically, an early shared object vs dynamic object approach. Obviously, modern languages don't work that way anymore because we have found better solutions and we have found it better to making libraries (i.e., mostly name spaces in todays languages) explicit rather than implicit. Optimizations for small pieces of code (rather than dynamically linking that code) is then just a matter of inlining and optimization at the compiler / linker optimization.

[pidgeon777]

Thanks for the detailed answer.

Thus, we can continue to instantiate our entities the same way (INSTANCE_LABEL: entity work.ENTITY_NAME), without any modification to the source code.

It will be enough to update our vhdl_ls.toml project file, changing the occurrences from work to, for example, worklib.

[Mark Brett]

I think this may come up again and again with this change. Might it be a good idea to issue a specific error message when the vhdl_ls.toml contains a library named work?

[Lukas Scheller]

I think this may come up again and again with this change. Might it be a good idea to issue a specific error message when the vhdl_ls.toml contains a library named work?

I agree. This Should already have been implemented but I can reproduce that this error is not shown (at least in VSCode). So this is a bug then.

[Lukas Scheller]

Can this be closed with #257?