Add originating function info to onLocalDeclaration

[pablomayobre]

This commit is related to the pull request #38 which added onLocalDeclaration, both target the specific use case of dapetcu21/atom-autocomplete-lua.

This pull request adds information about the function where the local value is being used, this allows Autocomplete-Lua to check whether the value's type is the expected for said function.

This is of course only necessary for functions so other elements don't pass the optional data object.

This commit was actually made by @dapetcu21 at dapetcu21/luaparse@5a1fd28 I have only rebased it

[dapetcu21]

I was meaning to do this PR myself when I got time, but I didn't do it yet because I wasn't fully happy with the semantics. For example, I'm not completely happy about the fact that the data object is not passed for non-functions. Any opinions?

(Also, there should be tests/docs for this)

[pablomayobre]

I understand what you mean, I just wanted to start discussion on it!

the data object gives the context of where the variable will be declared, which is useful when considering functions since you are getting the arguments.

The other cases where this function is being called:

• Aren't part of a scope (local statements or labels)
• Or it isn't a useful scope which could later be called or executed somewhere else (for loops)

So I don't see any meaning in passing the data argument in these other cases.

Maybe we could use what kind of identifier we are talking about like ForVariable, LocalVariable, Label and FunctionArgument. Is there any other information which could be useful to have in this callback?

EDIT: Another thing that could be useful is the location (line, column) of the identifier for that declaration, which is currently not found anywhere

[fstirlitz]

name contains either a node with the function name or null (for function expressions); function names, even if present, are themselves subject to scoping and therefore potentially ambiguous. For the originally given use case of code completion, it would be useful to distinguish a local function foo() defined on line 15 from a function foo() defined on line 75.

[fstirlitz]

Given that identifiers are always added to the current scope, how about passing metadata identifying the scope to the onCreateScope callback instead? Whoever provides the callbacks can pluck out the information they want and maintain their own state. onLocalDeclaration can then receive only the kind of declaration encountered (local statement, for loop, formal parameter) and its location in the source code.

Labels are already distinguished from variables, by the way; their names are passed with the surrounding :: marks. Admittedly not the most efficient design, but...

[dapetcu21]

@fstirlitz That could work. If onCreateScope() identifies the new scope as a function scope and then onLocalDeclaration() subsequently calls back saying "this is a function argument", then that's enough information.