Unterminated (single-line) string literal does not raise an error

[berbun]

Samples

luaparse.parse("s='");
luaparse.parse('s="');
luaparse.parse("s='\\\n");
luaparse.parse('s="\\\n');

(unterminated multi-line string seems to raise an exception unless it is run on command-line.)

From command-line

>luaparse -c "local s=\""
{"type":"Chunk","body":[{"type":"LocalStatement","variables":[{"type":"Identifier","name":"s"}],"init":[{"type":"StringLiteral","value":"","raw":"\""}]}],"comments":[]}

>luaparse -c "local s='"
{"type":"Chunk","body":[{"type":"LocalStatement","variables":[{"type":"Identifier","name":"s"}],"init":[{"type":"StringLiteral","value":"","raw":"'"}]}],"comments":[]}

>luaparse -c "local s=[["
{"type":"Chunk","body":[{"type":"LocalStatement","variables":[{"type":"Identifier","name":"s"}],"init":[{"type":"StringLiteral","value":"","raw":"[["}]}],"comments":[]}

---

Rundown

The path goes down to
parsePrimaryExpression() which calls next() here, which calls lex(), appending EOF token.

[fstirlitz]

The multi-line strings bug appears probably because you're running an old version from the command line. Check your PATH.

The other two I can confirm. I was pretty sure this was tested already, but apparently not strictly enough. Should be easy to fix, though.

[berbun]

I installed it via npm i -g luaparse, the luaparse --v says "luaparse v0.2.1".

The other two I can confirm.

btw I added 2 more cases up there, just in case since you haven't noticed.

For the sake of completeness, the following is valid in LuaJIT (not sure about vanilla Lua):

s="1\
2"print(string.byte(s,1,#s))

Outputs:

49 10 50

By using \ followed by newline (CR/LR or both), it is substituted with \n (LF) char.

[fstirlitz]

Yes, the version available from npm is not fixed. Latest git master at least handles multi-line strings correctly.

[fstirlitz]

Fixed in 28afaef d49b641 c3e11ee.

(That should teach me not to work on several things at once.)