Closed SethGower closed 4 months ago
Is the bug reproducible? I.e., does what you describe always happen? I cannot reproduce the bug on VSCode, could that be something that only affects Neovim? (Not trying to shift the blame to somewhere else, just trying to reproduce it)
I was able to reproduce this consistently, given the example I put in the issue. Maybe it could be a neovim thing? I can try in VSCode, however I don't use that much, so I'll need to get it setup
I was unable to get it to reproduce in VSCode, however as I said, I can consistently get it to reproduce in neovim.
It would be hard to isolate where the issue resides (in the client vs server) since the feature that seems to be causing the issue was adding in v0.80. However, I just tried backing up my plugin environment to before I updated a lot of plugins in neovim on Thursday (which I think I did before experiencing this bug) to see if that solves it. When I had all of the old versions of the plugins loaded, I still get the issue.
Digging more, and I noticed that it doesn't seem to be happening when I use the minimal_init.lua
that nvim-lspconfig
provides, when using the "Omnifunc" completion. So this could be related to my autocompletion setup? I'll dig more
Quick update: The panic doesn't happen when selecting a completion candidate when filling a port map of an instantiation.
So if in another module I were instantiating my example entity described above, if I typed o_|
(where |
is my cursor), it would give me options including o_q
and o_qn
, if I hit Tab to select one, it doesn't crash. However if I try to select a signal/port within the same module, it does crash.
Did some digging with the above observation. Here's the log for when I first try and complete a port in the port map when instantiating an object (which succeeds), then I try to associate it with a completion to a local signal/port (which fails)
Here is the contents of test2.vhd
(test1.vhd
is the module from the original issue report). I realize the association for o_qn
is garbage, it's what I typed and I didn't wanna redo the whole test, this still shows the panic properly.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity test2 is
port (
i_clk : in std_logic;
i_switches : in std_logic_vector(7 downto 0);
o_leds : out std_logic_vector(7 downto 0)
);
end entity test2;
architecture behav of test2 is
signal s_leds_not : std_logic_vector(7 downto 0);
begin
dff_generate : for i in 0 to 7 generate
test1_0 : entity work.test1
port map (
i_clk => i_clk,
i_rstn => '1',
i_d => i_switches(i),
o_q => o_leds(i),
o_qn => not o_leds
);
end generate dff_generate;
end architecture behav;
Sorry I am sort of blowing this issue up, hope I'm not spamming your inboxes too much. If discussion should be moved elsewhere, let me know
Here are more detailed error outputs
Sorry I am sort of blowing this issue up, hope I'm not spamming your inboxes too much. If discussion should be moved elsewhere, let me know
Here are more detailed error outputs
RUST_BACKTRACE=1 RUST_BACKTRACE=full
Don't worry about spamming my inbox, your efforts are greatly appreciated. I suspect that somehow the Entity Id gets lost in translation. This might be an issue with vhdl_ls, or the client. When completing items, servers can attach some data that the client will echo to request more information. For some reason, in this echo process, the entity id sent back from the client is no longer valid. The relevant code can be found here. Maybe it's worth adding a debug statement to see the entity ID echoed by the client and the entities in the pool here? In either way, the server should probably handle this more gracefully and not crash because some faulty ID was sent.
Hello. It seems that the LSP is panicking and exiting with exit code
101
when I try to complete a port name.Minimal example:
vhdl_ls
versionv0.80.0
Client: Neovim with latestnvim-lspconfig
, LSP installed withmason
. Using the default configuration innvim-lspconfig
, but here is my config for the LSP.vhdl_ls.toml
VHDL File
If I try to add
o_qn <= not o_q
, by typing outo_
and then selecting the autocomplete candidate from the LSP, I get the crash. Seems to be a rust panic. I have attached the log for the whole LSP session. The only related line seems to be the last one, however I figured I'd include it allSeems to be pointing to an error related the the dict not having a key here https://github.com/VHDL-LS/rust_hdl/blob/56f17db69a56b0e094667a9da83fb17cd20922c2/vhdl_lang/src/named_entity/arena.rs#L113