Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Erroneous "Opening file that is not part of the project" message #115

Closed
Zalfrin opened this issue Jul 28, 2021 · 7 comments
Closed

Erroneous "Opening file that is not part of the project" message #115

Zalfrin opened this issue Jul 28, 2021 · 7 comments
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed

Comments

@Zalfrin
Copy link

Zalfrin commented Jul 28, 2021

I'm using VHDL LS from inside vscode running on Windows. When I open a project that is located on my local disk drive (C:), everything works fine. However, if I take the same project and move it to a NAS drive on our network, LS no longer recognizes the VHDL files as belonging to a project.

Maybe network latency is causing something weird to happen?

While investigating, I found a similar bug report for a different extension with a detailed explanation, may or may not be related. https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/290#note_475873929

I'll attach the project I am testing with. It also contains the logs that are produced in vscode with verbose trace running (one for project being locally stored and one for when it is on a NAS drive).

vhdl_ls_mre.zip

@kraigher
Copy link
Member

kraigher commented Dec 7, 2022

It is probably something with the search paths on windows and different drives. You can build vhdl ls locally and debug it to see if you can solve the problem. The code that loads the configuration file and creates the search paths is here: https://github.com/VHDL-LS/rust_hdl/blob/master/vhdl_lang/src/config.rs

@kraigher kraigher added bug Something isn't working help wanted Extra attention is needed good first issue Good for newcomers labels Dec 7, 2022
@kraigher
Copy link
Member

kraigher commented Feb 5, 2023

Closed due to lack of activity

@kraigher kraigher closed this as completed Feb 5, 2023
@Matt-D-Smith
Copy link

I'm encountering this exact issue as well, and it appears someone on the vscode extension issues tracker is as well. I don't have rust experience, but have a little bit with C, so I tried to take a look at this, but there seems to be no build/debug instructions. I could figure out how to build, but not how to debug it.

@kraigher
Copy link
Member

@Matt-D-Smith you can use eprintln!() and it will show up in the Output window in VScode if you select VHDL-LS Trace in the top left drop-down in the output window.

@kraigher kraigher reopened this Nov 11, 2023
@Matt-D-Smith
Copy link

Matt-D-Smith commented Nov 11, 2023

Some initial finding, within LibraryConfig() there is a fn as_abspath(). The file_path input to that is of format like ordinary windows file path for a network drive

\\sshfs.r\user@domain\mnt\drive\projects\test\test1.vhd

the code runs as_abspath(&file_path), and puts abs_path in result
abs_path is of format

\\?\UNC\sshfs.r\user@domain\mnt\drive\projects\test\test1.vhd

Seems to be an inconsistency somewhere in using this format file path and the original format file path, which is causing
"Opening file {} that is not part of the project"
to be triggered, unsure if this file path discrepancy causes issues elsewhere.

I have seen this issue cause VHDL_LS to think there is a duplicate entity of same name when only one entity of that name exists in the project.

@kraigher
Copy link
Member

@Matt-D-Smith could you try the https://github.com/VHDL-LS/rust_hdl/tree/file_path branch? I made a quick hack there to test a hypothesis on how this problem can be fixed.

@Matt-D-Smith
Copy link

Matt-D-Smith commented Nov 12, 2023

Building that branch, I no longer see the "Opening file that is not part of the project" warning with either the workspace file path being the network file path format \\server\share\folder or the network mapped drive format Z:\folder. Seems like that worked!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants