Remove implicit conjunction #16
Conversation
| @@ -679,12 +679,6 @@ local function parse_logical_or_arithmetic(lexer, max_precedence) | |||
| if prec then | |||
| if prec > max_precedence then return exp end | |||
| lexer.consume(op) | |||
There was a problem hiding this comment.
this is an incorrect change because it will leave prec as nil. dunno what the right fix is; you might try to identify the patch that introduced this behavior and see how to revert it.
There was a problem hiding this comment.
OK, I thought it was mostly fixed due to #15. The point is that now when running "make check" the else branch is never executed, so that means for all the tested expressions 'prec' is never nil, but even if that case the patch should have removed the else branch and the check.
So would it still possible that there will be an expression for which 'prec' is nil? I will try to research more on this.
This patch fixes issues #16.
dpino
force-pushed
the
issue-16-remove-implicit-conjuction
branch
from
45c61f7
to
5940c73
Compare
|
This is marked as high-priority, but hasn't been closed or merged despite being open for months. Is the underlying issue fixed, or does this patch need to be updated and applied? |
|
@andywingo commented the proposed patch (remove the else branch) is not correct. I think that once the issue with parsing tcp port was fixed the else branch, that creates the implicit 'and', is no longer taken. |
I thought that since "tcp port 80" should parse as "tcp and port 80" that in fact the implicit "and" that the pflang spec mentions as obsolete was in fact current. This faulty conclusion was based on my bad understanding of how "tcp port 80" parses -- that in fact as issue #15 indicates, "tcp port 80" is one operator.
So, we should remove the implicit conjunctions from the parser.