As reported by Steffan on Discord, the &&s emitted to chain together relational ops have a lower precedence than those relational ops, which caused problems when surrounding them with ops that have precedence in between && and relational (namely, &, |, ^, and any custom operators set to have those precedence).
I'm not sure this is the cleanest solution. (Initially I thought we could do something when expanding chains, when we already have the && chain assembled — but parens are hard to add in there while maintaining the correct pattern of [data, ws, op, ws, data, ws, op, ws, ...].) This PR adds a custom operator type and ties into the existing precedence logic, which at least seemed simple to implement.
As reported by Steffan on Discord, the
&&s emitted to chain together relational ops have a lower precedence than those relational ops, which caused problems when surrounding them with ops that have precedence in between&&and relational (namely,&,|,^, and any customoperators set to have those precedence).I'm not sure this is the cleanest solution. (Initially I thought we could do something when expanding chains, when we already have the
&&chain assembled — but parens are hard to add in there while maintaining the correct pattern of[data, ws, op, ws, data, ws, op, ws, ...].) This PR adds a custom operator type and ties into the existing precedence logic, which at least seemed simple to implement.