Studio Editor should do a better job of helping me find missing block terminations

[14:17:11.353 - ServerScriptService.ItemManager:65: Expected ‘end’ (to close ‘function’ at line 4), got EOF

This code is missing an “end” statement somewhere.

Visual Studio would tell me where it was. Code editor gives me no help, other than it starts somewhere after the first line in my program.


A temporary workaround I use for finding where the missing block is could be a beautifier. Having code indented goes a long way.

A built-in solution would definitely be better, though. I’m not sure how VS manages it, it seems like a tough problem to solve.


Isn’t it quite subjective? Like you could be missing the end to that if statement you just wrote, or you could be missing the end to the first function, with the second function assumed to be nested inside.

Without strictly enforcing indentation it’s kind of impossible to know which block you intended to close but didn’t.

There’s 4 possible blocks that could be considered the unclosed block in this example.

There’s probably some black magic you can do with static analysis to figure out that in 3 of those cases the resulting code would error on execution.

But in this case just using the indentation as a hint would get one pretty far.


Personally, I think asking engineers to do “black magic” instead of just sticking to a indentation style is a bit unnecessary. That missing end would be blatantly obvious if you indented it the same as you did for every other if statement you wrote. Inconsistent styling is bad practice on your end, no offense.

It would be nice to have better error detection, sure, but it’s not as vital as you seem to be making of it.


I don’t think Visual Studio really detects cases like this for C++ or C#. C# has a stricter syntactic structure than Lua which means that in some cases the errors can be caught early, e.g. just because it’s invalid to say private void foo() inside another method’s body. (that’s not a universally accepted or favorable syntactic property btw, JS for example doesn’t have that, and the errors there due to missing } are obtuse, typically inferior to what we have)

But of course this doesn’t stop us from trying to make this even better.