1
Vote

cannot correctly parse return statement

description

The DocumentParser.Parse method sometimes cannot correctly parse the return statement in any block. If there are any statements before the return statement, the return keyword (KWRETURN) might be considered syntaxtical illegal.
I can figured this problem out by going deeply into the parser code, but cannot tell how to fix it. I tried to modify the parser.y file but failed.
Parsing the following Lua code will recreate this issue:
-- The following code can be correctly parsed
function foo()
return 3
end
-- The following code will be parsed with the return statement lost
function foo()
local a = 3
return a
end

comments

hillin wrote Nov 10, 2010 at 1:52 PM

sorry but I misspelled the class name DocumentationParser

Celess wrote May 27, 2012 at 10:21 PM

Yes, the "return" situation in this version is pretty much a sad monkey.

The short explanation is:
This is because return is only legal in the .y as a "last statement", and thus, on error, invalidates the whole block... and the containing blocks... like a little parser virus. Once the parser sees return and then return expression code afterward, it simi-commits the block to that "type" of block. There is also "bug" sort of where an expression thats LR(0) like "bob and fred" but missing the right side, like just "bob and", has special issues during error recovery. So if you type as much as "return bob and" and the parser "eats" all the blocks getting to the top of the parser chunk, with no independant valid blocks who arnt its parent to block the parser from hitting the top, it can go into an infinate loop, and lock the parser thread, spinning a core at 100% for the duration of your AddOn Studio session with no subsequent intellisense feedback.

There are a couple of ways to solve this. But fundamentally, while the sort of conceptual correctness of creating a block "type" of "last statement" using "return expression" with as one of the options is sound, its inappropriate with this particular parser engine, whether the resultant tree was to be run in an interpreter, or if it was being used as feedback for an editor. The problem is that neither case needs a block to be invalidated, just the statement, like any other. In this case its placing the error on the block effectively. Even if that wernt an issue and the error situation was that the error was that there was code after the return in the same block, depending on the feedback needs, its the code after thats not following the program, not an error with return, unless there is an error wiht the return statement too.

Celess wrote May 27, 2012 at 10:37 PM

To clarify the last part... this particular last statement issue for this parser would be fine (sans the infiniate loop issue) if the situation was for a compiler to all-or-nothing compile a chunk needing only the error/warning log feedback, but not for anyting that needs valid tree, like an editor or interpreter.