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

Parameter confusion where a global function with the same name is defined in multiple files #826

Closed
zejji opened this issue Nov 25, 2021 · 1 comment
Labels
bug Something isn't working
Milestone

Comments

@zejji
Copy link

zejji commented Nov 25, 2021

Description

Where a function with the same name is defined (with a function body) multiple times in different files, Lua Language Server assumes that there is only one function and merges together the @param annotations (and presumably any other annotations?) for all the functions.

For example, in a Defold game engine project, each script file has the same set of functions defined in the global space, e.g.:

function init(self)
	-- Add initialization code here
	-- Learn more: https://defold.com/manuals/script/
	-- Remove this function if not needed
end

function update(self, dt)
	-- Add update code here
	-- Learn more: https://defold.com/manuals/script/
	-- Remove this function if not needed
end

-- other functions omitted for brevity

In a real Defold project, there will be many such scripts. See below for an example from a newly-created project I am working on. Although I have only added the annotation ---@param obj LevelSelectGui for the on_message method (at line 15), when I hover over the obj parameter it shows it as a union of all the different on_message functions in my various script files. This is because there are other on_message functions in separate level.gui_script and main.script files.

image

To Reproduce

Steps to reproduce the behavior:

  1. Create the same-named global function with the same-named arguments in more than one file.
  2. Add different parameter annotations in each file (i.e. a different type for the same-named argument in each file).
  3. Hover over the relevant parameter in one file. Lua Language Server will show the type of the parameter as a union of all the types annotated in the different files.

Expected behavior

I would expect that, where a function is defined multiple times with a method body (as opposed to merely a forward declaration), Lua Language Server should regard each definition as a different function and should not merge annotations for the different implementations.

Environment:

  • OS: Windows 10 (not using WSL remote server)
  • Client: VSCode with lua-language-server v2.4.11
@zejji
Copy link
Author

zejji commented Nov 25, 2021

For completeness, here is the forward declaration of the on_message function that is implemented in each of the scripts. This forward declaration is auto-generated from the Defold documentation using this utility:

---This is a callback-function, which is called by the engine whenever a message has been sent to the script component.
---It can be used to take action on the message, e.g. send a response back to the sender of the message.
---The message parameter is a table containing the message data. If the message is sent from the engine, the
---documentation of the message specifies which data is supplied.
---@param self object reference to the script state to be used for storing data
---@param message_id hash id of the received message
---@param message table a table containing the message data
---@param sender url address of the sender
function on_message(self, message_id, message, sender) end

Arguably it makes sense to:

  • merge the annotations from the forward declaration and the implementation (with the implementation annotations taking priority in the case of conflict) where they both have the same number of arguments; but
  • not to merge annotations between different implementations of the function (i.e. where there is a function body), as there is no way that multiple implementations could be referring to the same function.

Perhaps this distinction would be over-complicating things - however, having the forward declaration annotations available while coding an implementation would be a genuine help in day-to-day coding.

In any case, I think the second point above (i.e. not merging annotations from different implementations) is the most important, as the current type hinting is incorrect.

@sumneko sumneko added the bug Something isn't working label Nov 26, 2021
@sumneko sumneko added this to the 2.6.0 milestone Nov 29, 2021
@sumneko sumneko closed this as completed in 90b5385 Dec 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants