[ 
https://issues.apache.org/jira/browse/HIVE-6264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885852#comment-13885852
 ] 

Hive QA commented on HIVE-6264:
-------------------------------



{color:green}Overall{color}: +1 all checks pass

Here are the results of testing the latest attachment:
https://issues.apache.org/jira/secure/attachment/12625831/HIVE-6264.4.patch

{color:green}SUCCESS:{color} +1 4972 tests passed

Test results: 
http://bigtop01.cloudera.org:8080/job/PreCommit-HIVE-Build/1101/testReport
Console output: 
http://bigtop01.cloudera.org:8080/job/PreCommit-HIVE-Build/1101/console

Messages:
{noformat}
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase
{noformat}

This message is automatically generated.

ATTACHMENT ID: 12625831

> Unbalanced number of HiveParser msgs.push/msgs.pop calls when doing lookahead
> -----------------------------------------------------------------------------
>
>                 Key: HIVE-6264
>                 URL: https://issues.apache.org/jira/browse/HIVE-6264
>             Project: Hive
>          Issue Type: Bug
>            Reporter: Jason Dere
>            Assignee: Jason Dere
>         Attachments: HIVE-6264.1.patch, HIVE-6264.2.patch, HIVE-6264.3.patch, 
> HIVE-6264.4.patch
>
>
> HiveParser pushes/pops messages describing the current parse rule like so:
> {noformat}
> joinSource
> @init { gParent.msgs.push("join source"); }
> @after { gParent.msgs.pop(); }
> ...
> {noformat}
> The ANTLR generated code for the init/after actions looks like this:
> {noformat}
>          gParent.msgs.push("join source"); 
> ...
>             if ( state.backtracking==0 ) { gParent.msgs.pop(); }
> {noformat}
> If we have a parse rule that does some lookahead, the message is always 
> pushed onto the message stack since the init action has no check of 
> state.backtracking.  But that message is never popped because the after 
> action does check state.backtracking. As a result there can be a bunch of 
> parser context messages added to the stack which are never taken off.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to