-
-
Notifications
You must be signed in to change notification settings - Fork 415
Description
How are you using the lua-language-server?
Visual Studio Code Extension (sumneko.lua)
Which OS are you using?
Linux
What is the issue affecting?
Diagnostics/Syntax Checking
Expected Behaviour
Intuitively, I expected:
---@sourceannotations in meta files with relative paths to be resolved relative to the workspace- VS Code variables in the
@sourcepath to be resolved when resolving a path
Actual Behaviour
@sourcepaths are resolved relative to the meta file itself- VS Code variables in the path are not resolved
Reproduction steps
- Create
.vscode/luals/library/foo.d.luawith:---@meta --- @class foo _G.foo = {} ---@source grault/foo.lua:1 function bar() end
- Create
baz.luawith:require("foo") local quux = foo.bar()
- In extension settings, set:
{ "Lua.workspace.userThirdParty": ["${fileWorkspaceFolder}/LuaLS"] }
Note
The variable ${fileWorkspaceFolder} resolves correctly and adds the meta file to the list of search paths
- Open
baz.luain VS Code editor - Right click
bar - Select
Go to Definition - Observe:
VS Code opens a non-existent source file tab to.vscode/luals/library/grault/foo.lua
Additional Notes
This could be two separate issues, but they're tightly related -- one as a Documentation Issue that the relativity of the resolution of the path should be added to the docs, and two as a Bug/Feature Request that VS Code variables be resolved in the @source paths as they are in the settings
Attempting to work around this using VS Code variables has the variable unresolved and taken literally. For example, setting the @source path to /${fileWorkspaceFolder}/grault/foo.lua:1 causes VS Code to open a tab to that literal string instead of the expected /home/me/my_project/grault/foo.lua:1
Log File
No response