harec

commit 411297c121980d3df1d85596358014158aae6a66
parent 1bd2424a4908f20326eb90bb5b1f65e5a92f8c74
Author: Eyal Sawady <ecs@d2evs.net>
Date:   Thu, 24 Dec 2020 00:53:02 -0500

Fix parsing of the unary-expression case of scope-expression

- Move unary operators out of the complex-expression case, to fix
  `*+foo = 0` et al
- Refactor the unary-expression case to always use
  parse_unary_expression rather than using parse_postfix_expression for
  non-indirect cases. There's no case when a postfix-expression could
  begin a scope-expression and a unary-expression couldn't, and this
  allows us to use this case for unary operators as well

Diffstat:
M
src/parse.c
 | 
17
++++-------------

1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/src/parse.c b/src/parse.c
@@ -864,26 +864,17 @@ parse_scope_expression(struct parser *par)
 	case T_IF:
 	case T_FOR:
 	case T_MATCH:
-	case T_SWITCH:	// complex-expression
-	case T_PLUS:
-	case T_MINUS:
-	case T_BNOT:
-	case T_LNOT:
-	case T_BAND:	// unary-expression, w/o pointer dereference
+	case T_SWITCH:
 		unlex(par->lex, &tok);
 		value = parse_complex_expression(par);
 		if (indirect) {
 			assert(0); // TODO: Wrap value in unary dereference
 		}
 		return value;
-	default:	// postfix-expression
+	default:
 		unlex(par->lex, &tok);
-		if (indirect) {
-			value = parse_unary_expression(par);
-			break;
-		}
-		value = parse_postfix_expression(par);
-		if (value->type != EXPR_ACCESS) {
+		value = parse_unary_expression(par);
+		if (!indirect && value->type != EXPR_ACCESS) {
 			return value;
 		}
 		// Is possible object-selector, try for assignment