Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SPARK-13277][SQL] ANTLR ignores other rule using the USING keyword #11168

Closed
wants to merge 1 commit into from

Conversation

viirya
Copy link
Member

@viirya viirya commented Feb 11, 2016

JIRA: https://issues.apache.org/jira/browse/SPARK-13277

There is an ANTLR warning during compilation:

warning(200): org/apache/spark/sql/catalyst/parser/SparkSqlParser.g:938:7: 
Decision can match input such as "KW_USING Identifier" using multiple alternatives: 2, 3

As a result, alternative(s) 3 were disabled for that input

This patch is to fix it.

@viirya
Copy link
Member Author

viirya commented Feb 11, 2016

cc @hvanhovell

@SparkQA
Copy link

SparkQA commented Feb 11, 2016

Test build #51089 has finished for PR 11168 at commit 4cb9d2a.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@hvanhovell
Copy link
Contributor

@viirya thanks for working on this. Do you have an idea what functionality was disabled?

@viirya
Copy link
Member Author

viirya commented Feb 11, 2016

@hvanhovell there are two alternatives to match tableProvider rule:

     tableProvider
     tableOpts?
     (KW_AS selectStatementWithCTE)?

And

(LPAREN columnNameTypeList RPAREN)?
     (p=tableProvider?)
...

Because (LPAREN columnNameTypeList RPAREN) is optional, an input KW_USING Identifier can be matched with both paths. So the warning is emitted and path 1 is chosen and path 2 is disabled. Actually it doesn't affect the functionality we need.

@hvanhovell
Copy link
Contributor

LGTM

@hvanhovell
Copy link
Contributor

Merging to master. Thanks!

@asfgit asfgit closed this in e31c807 Feb 11, 2016
@rxin
Copy link
Contributor

rxin commented Feb 11, 2016

Can we add a unit test for this?

@hvanhovell
Copy link
Contributor

We could add a unit test for this specific case. But I am also looking for a way to treat these warnings as compile errors; which would be a lot better.

@rxin
Copy link
Contributor

rxin commented Feb 11, 2016

Yup that's a great idea.

@viirya viirya deleted the fix-parser-using branch December 27, 2023 18:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants