Why doesn’t local a \n = 3 work like in standard Lua?

[yuychu]

Lua-CSharp/src/Lua/CodeAnalysis/Syntax/Parser.cs

Lines 115 to 143 in ad6a5a1

	case SyntaxTokenType.Local:
	{
	// skip 'local' keyword
	CheckCurrentAndSkip(ref enumerator, SyntaxTokenType.Local, out var localToken);
	// local function
	if (enumerator.Current.Type is SyntaxTokenType.Function)
	{
	// skip 'function' keyword
	CheckCurrentAndSkip(ref enumerator, SyntaxTokenType.Function, out var functionToken);
	enumerator.SkipEoL();
	return ParseLocalFunctionDeclarationStatement(ref enumerator, functionToken);
	}
	CheckCurrent(ref enumerator, SyntaxTokenType.Identifier);
	var nextType = enumerator.GetNext().Type;
	if (nextType is SyntaxTokenType.Comma or SyntaxTokenType.Assignment)
	{
	return ParseLocalAssignmentStatement(ref enumerator, localToken);
	}
	else if (nextType is SyntaxTokenType.EndOfLine or SyntaxTokenType.SemiColon)
	{
	return new LocalAssignmentStatementNode([new IdentifierNode(enumerator.Current.Text, enumerator.Current.Position)], [], localToken.Position);
	}
	}
	break;

Hi,

In standard Lua, the following code is valid:
local a
= 3
But in this implementation, it throws a syntax error.

Is there a reason this form isn’t supported?

Thanks.

[yuychu]

I think the second condition check for "is EndOfLine" on nextType should be removed.

nextType に対するis EndOfLine 条件判定は削除すべきだと思います。

[yuychu]

🥺

[tweigt]

I also have a similar problem (LuaCSharp 4.2).

Here is a stripped down example:

var state = LuaState.Create();
try
{
  await state.DoStringAsync(@"myf = function()
    return
    {
      a =
      1
    }
  end");
}
catch (Exception ex)
{
  Console.WriteLine(ex.ToString());
}

Here is the exception:

Lua.LuaParseException: :(4,7): Unexpected token <EndOfLine>
   at Lua.CodeAnalysis.Syntax.Parser.ParseExpression(SyntaxTokenEnumerator& enumerator, OperatorPrecedence precedence)
   at Lua.CodeAnalysis.Syntax.Parser.ParseTableConstructorExpression(SyntaxTokenEnumerator& enumerator)
   at Lua.CodeAnalysis.Syntax.Parser.TryParseExpression(SyntaxTokenEnumerator& enumerator, OperatorPrecedence precedence, ExpressionNode& result)
   at Lua.CodeAnalysis.Syntax.Parser.ParseExpressionList(SyntaxTokenEnumerator& enumerator)
   at Lua.CodeAnalysis.Syntax.Parser.ParseReturnStatement(SyntaxTokenEnumerator& enumerator)
   at Lua.CodeAnalysis.Syntax.Parser.ParseStatement(SyntaxTokenEnumerator& enumerator)
   at Lua.CodeAnalysis.Syntax.Parser.ParseStatementList(SyntaxTokenEnumerator& enumerator, SyntaxTokenType endToken)
   at Lua.CodeAnalysis.Syntax.Parser.ParseFunctionDeclarationCore(SyntaxTokenEnumerator& enumerator, Boolean isAnonymous)
   at Lua.CodeAnalysis.Syntax.Parser.ParseFunctionDeclarationExpression(SyntaxTokenEnumerator& enumerator)
   at Lua.CodeAnalysis.Syntax.Parser.TryParseExpression(SyntaxTokenEnumerator& enumerator, OperatorPrecedence precedence, ExpressionNode& result)
   at Lua.CodeAnalysis.Syntax.Parser.ParseExpressionList(SyntaxTokenEnumerator& enumerator)
   at Lua.CodeAnalysis.Syntax.Parser.ParseAssignmentStatement(ExpressionNode firstExpression, SyntaxTokenEnumerator& enumerator)
   at Lua.CodeAnalysis.Syntax.Parser.ParseStatement(SyntaxTokenEnumerator& enumerator)
   at Lua.CodeAnalysis.Syntax.Parser.Parse()
   at Lua.CodeAnalysis.Syntax.LuaSyntaxTree.Parse(String source, String chunkName)
   at Lua.LuaStateExtensions.DoStringAsync(LuaState state, String source, Memory`1 buffer, String chunkName, CancellationToken cancellationToken)
   at Lua.LuaStateExtensions.DoStringAsync(LuaState state, String source, String chunkName, CancellationToken cancellationToken)

If I change the lua code like this it works:

myf = function()
  return
  {
    a = 1
  }
end

Unfortunately I cannot change the lua code.

@yuychu have you tried other implementations?

[yuychu]

The issue lies in the parser: when it encounters the local keyword followed by an identifier, if the next token is a newline, it immediately returns a LocalAssignment node with an empty rightNodes. As a result, the equals sign at the beginning of the next line is ignored.

Then, when parsing continues with ParseStatement, it throws an error because no valid statement can begin with an equals sign.

This is easy to fix—just always use ParseLocalAssignmentStatement, which can correctly handle all such cases. I suspect the author opted to directly return a new LocalAssignmentStatementNode in the second condition for performance reasons, but this shortcut is logically unnecessary.

Of course, the simplest workaround is to avoid splitting assignment statements across lines.
@tweigt

[nuskey8]

fixed in #176