Parser generates ListExpr in many cases when it shouldn't

RESOLVED FIXED

Status

Tamarin
Self-hosting compiler (ESC)
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Lars T Hansen, Assigned: Lars T Hansen)

Tracking

Details

Attachments

(1 attachment)

(Assignee)

Description

10 years ago
This returns false as it should:
  delete Boolean.prototype

This returns true:
  delete (Boolean.prototype)
(Assignee)

Comment 1

10 years ago
This is an instance of a general parser bug wherein the parser returns Ast::ListExpr nodes far too often.  The grammar production in question is ListExpression, but this production is overloaded to be used both on function parameters and on comma expressions.  The latter cases should (probably) be rewritten to use a CommaExpression production which produces a simple expression if there's only one and Ast::Comma(x,y) otherwise.  Note, this may cause some wrinkles in cogen which depends on Ast::ListExpr in a couple of places.
(Assignee)

Comment 2

10 years ago
Also a problem for "typeof (x)" for the same reason.
(Assignee)

Updated

10 years ago
Summary: delete operator is wonky → Parser generates ListExpr in many cases when it shouldn't
(Assignee)

Comment 3

10 years ago
Created attachment 311190 [details] [diff] [review]
Patch

Removes ListExpr from ESC, substitutes CommaExpr and cleans up some hacks that were necessary to support ListExpr previously.
Attachment #311190 - Flags: review?(jodyer)

Comment 4

10 years ago
Comment on attachment 311190 [details] [diff] [review]
Patch

This matches my updated grammar with one difference being is renamed parenListExpression to parenExpression rather than parenCommaExpression
Attachment #311190 - Flags: review?(jodyer) → review+
(Assignee)

Comment 5

10 years ago
Changeset 485:ca35d6ab0083
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Comment 6

10 years ago
Was never pushed, new changeset 492:9068d6de7549
You need to log in before you can comment on or make changes to this bug.