Parse error in multiline attribute expression

[Scony]

Godot version:
master @ d11d7df

OS/device including version:
Linux

Issue description:
Godot raises parse error on the code below:

class X:
	func foo(p):
		var x = (
			p
			.some
			.some
			.some
		)

Godot Engine v3.2.rc.custom_build.d11d7dfe3 - https://godotengine.org
 
SCRIPT ERROR: GDScript::reload: Parse Error: Expected ')' in expression
   At: res://tests/potential-godot-bugs/multiline-attribute-expression.gd:5.
ERROR: reload: Method/Function Failed, returning: ERR_PARSE_ERROR
   At: modules/gdscript/gdscript.cpp:576.

[Calinou]

I think the only way to chain methods on newlines right now is to add backslashes at the end of every line.

[Scony]

Well, this is a bit counter-intuitive since python (which GDScript is motivated by) has no problems with such a code. Also, it's useful for formatting in case of such a long attr/call chains.

[Calinou]

The issue is that the .method() syntax is used to call a method on the parent class. Therefore, it'd be ambiguous to support chaining methods without a backslash (unless we change the parent method call syntax).

[Scony]

Actually it doesn't matter. You cannot have an attribute expression starting with a dot (like .aaa.bbb.ccc). And hence there is no ambiguity - from pure parsing perspective, the expression starting with dot must be a parent call. And please note that newline should not matter inside of any expression (maybe except long string """xxx""").

[Calinou]

@Scony Right, so we can support it for property access but not for method calls. That's pretty inconsistent, so I'm still not sure if we should support that 🙁

[Scony]

@Calinou what do you mean by but not for method calls?

[dalexeev]

var x = (
    p
    .some
    .some
    .some
)

I am not a fan of this style of code, but specifically in this case, the parser is wrong. Since the expression is enclosed in parentheses, indents should be treated as spaces:

var x = (p .some .some .some)

Probably the problem is that in the current implementation of the parser, indentation is treated the same way, regardless of context (operator stream or expression).

ADD. The same code, but without parentheses, I think, should really cause a parse error:

var x = p
    .some
    .some
    .some

[bojidar-bg]

Probably the problem is that in the current implementation of the parser, indentation is treated the same way, regardless of context (operator stream or expression).

Actually the problem is simpler: The code in the parser currently does not try parsing newlines interspersed in indexing operations, the way the code related to parsing parts of an expression does. (and, no, x.y is not really an operator, since y is not a valid expression on its own)

Code not checking for a newline in x<newline>.y

godot/modules/gdscript/gdscript_parser.cpp

Lines 1178 to 1182 in 1c6d1fc

	while (true) {
	//expressions can be indexed any number of times
	if (tokenizer->get_token() == GDScriptTokenizer::TK_PERIOD) {

Code checking for a newline in x +<newline>y:

godot/modules/gdscript/gdscript_parser.cpp

Lines 255 to 260 in 1c6d1fc

	if (parenthesis > 0) {
	//remove empty space (only allowed if inside parenthesis
	while (tokenizer->get_token() == GDScriptTokenizer::TK_NEWLINE) {
	tokenizer->advance();
	}
	}

Code checking for a newline in x<newline>+ y:

godot/modules/gdscript/gdscript_parser.cpp

Lines 1295 to 1300 in 1c6d1fc

	if (parenthesis > 0) {
	//remove empty space (only allowed if inside parenthesis
	while (tokenizer->get_token() == GDScriptTokenizer::TK_NEWLINE) {
	tokenizer->advance();
	}
	}

Keep in mind that a similar check would be needed for p.<newline>some, and maybe p.some<newline>(.

Finally, note that the following is valid syntax:

func a():
    var b = c # Important: no parentheses around c<newline>.d()
    .d()

It stands for a call to d() in the base/super class.

[JohnCorby]

cant this pretty easily be fixed with 4.0 since it will use super.thing instead of just .thing to get superclass methods/fields? when that happens, doing this chaining (with or without parenthesis) wont be ambiguous for the parser, right?

[KoBeWi]

Fixed in 4.0