Support specifying globals inside Lua files

[Zamiell]

Currently, when using this language server, you get warnings for global variables:

if someGlobalVariable then -- Undefined global `someGlobalVariable `. Lua Diagnostics.(undefined-global)
  print("wow!")
end

The way to squelch them is to add the globals to the VSCode settings. But this is too much of a sledgehammer, as we might only want the globals to be enabled in this specific file. Thus, we should also add a feature so that end-users can specify the globals in-line:

-- We specify a list of globals at the top of the file.
-- @global someGlobalVariable 

someCode()

if someGlobalVariable then -- No warning.
  print("wow!")
end

[necauqua]

A suggestion is to also support a subset of laucheck options for this. So syntax like -- luacheck: globals g1 g2 g3 will add g1, g2 and g3 as globals.

Also might load globals from .luacheckrc, although this is way more complicated I guess

[somebody1234]

or if that's too much you could probably just hijack emmylua syntax and do --- @globals g1 g2 g3 (optionally with commas) (or rather than too much, if it's just kinda weird using a completely different syntax just to be compatible with luacheck)

[necauqua]

I did not suggest replacing emmylua syntax or whatever, I suggested to support the luacheck syntax additionally, for projects that use luacheck, for the usability of the feature to be way broader

[somebody1234]

right... but my point is more that, not only can you not specify types, but also you'd explicitly have to add specialcasing for this specific syntax... the implication of that would be that supporting syntaxes from other tools is fair game too which can quickly lead to its features being a mess

(tl;dr i think --- @globals (or --- @global to match with --- @return not being plural?) is a reasonable alternative to supporting some arbitrary syntax)

note also that OP seems to want a way to enable globals in a specific file - which i don't think .luacheckrc lets you do

[necauqua]

Okay, so this is a generic Lua LSP (at least the best attempt at it), and also it states that while their custom annotations are based on EmmyLua, it's not EmmyLua. There is no "competition" here between EmmyLua and "other tools".

"Specialcasing" support for a single bit of syntax of an extremely popular tool that otherwise clashes and creates unpleasant experience is something that a generic Lua LSP probably should do - in fact it should support luacheck completely, but I didn't even ask for that, just for one bit that will definitely be pretty annoying.

enable globals in a specific file - which i don't think .luacheckrc lets you do

Huh well first of all it literally does, and second of all there's the inline luacheck syntax that I mentioned in the first place.

And my whole suggestion was only because the "specialcasing" should be pretty easy - just add the globals from the luacheck inline syntax to the list of globals that the lsp knows about that you are going to implement for this feature anyway, just handling an extra bit of syntax should be pretty easy.

[somebody1234]

while their custom annotations are not EmmyLua, that is only with respect to the annotations themselves. i'm relatively sure the syntax for declaring annotations (i.e. --- @annotation) is still identical to EmmyLua

also i don't think it would create an "unpleasant experience" if the language server just adds its own --- @global, which, importantly, would support type annotations

also worth noting that the language server has significant overlap with luacheck - unused vars, redefined vars, unused args, unused labels etc... many of which have their own config options

and so the point is, after you add this feature, what's to stop someone from requesting other features since the support would basically be there already?

and so in the extreme case, this may just turn into an implementation of luacheck

also worth noting that because of the large overlap with luacheck there's a lot less of a point having both tools - at some point it's probably easier/better to just install the luacheck extension instead...

[carsakiller]

Since the annotations for the language server are no longer cross-compatible with EmmyLua annotations since v3, the annotations have sort of become their own "Sumneko Lua Annotations". I think it is time this be made official to avoid confusion.

Adding @global is consistent with all other already existing annotations, and, like @somebody1234 said, the parsing of the AST already handles ---@ style annotations — adding support for luacheck would require a new special case to be added to handle the new syntax. It would be nice to document with one annotation style for both applications, but, like @somebody1234 said, it seems like it would snowball into fully supporting luacheck when this project is still ironing out itself. Adding support for other community tools could be a good project for later, I just don't think it is a priority right now. If you would like to see support added, I still encourage you to open an issue about it so it can be tracked. You are of course also welcome to open a PR to contribute the changes yourself.

[FlashHit]

@sumneko Hm maybe you could do this along with

• #900