Skip to content

Resolve parser choice conflicts by adjusting lookahead in index-related rules #2217

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

Merged
merged 1 commit into from
Apr 8, 2025

Conversation

minleejae
Copy link
Contributor

Hi @manticore-projects,

This PR addresses multiple parser choice conflicts by increasing the LOOKAHEAD values in the index-related grammar rules.

✅ Resolved Warnings:
The following conflicts have been resolved:

Warning: Choice conflict in (...)* construct at line 7661, column 5.
         Expansion nested within construct and expansion following construct
         have common prefixes, one of which is: "WITH"
         Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict involving two expansions at
         line 7860, column 17 and line 7888, column 17 respectively.
         A common prefix is: "SPATIAL" "COMMENT"
         Consider using a lookahead of 3 or more for earlier expansion.

⚠️ Remaining Warnings:
However, the following two warnings still remain:

Warning: Choice conflict in [...] construct at line 7863, column 19.
         Expansion nested within construct and expansion following construct
         have common prefixes, one of which is: "INDEX"
         Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 8363, column 9.
         Expansion nested within construct and expansion following construct
         have common prefixes, one of which is: "WITH"
         Consider using a lookahead of 2 or more for nested expansion.

From what I can tell, these may stem from ambiguities involving Identifier vs keyword-based starts (INDEX, WITH, etc.). I suspect a deeper refactoring of how Identifier and keyword lookahead are handled might be needed.

If there’s a better pattern or common best practice to resolve such nested choice conflicts (especially those involving Identifier vs keyword lookahead), I’d appreciate your advice before going further.

Thanks!

@manticore-projects manticore-projects merged commit f77825f into JSQLParser:master Apr 8, 2025
3 of 4 checks passed
manticore-projects added a commit that referenced this pull request Apr 8, 2025
- completes #2217

Signed-off-by: Andreas Reichel <[email protected]>
@manticore-projects
Copy link
Contributor

Thanks, I have completed the rest.
Cheers!

@minleejae
Copy link
Contributor Author

@manticore-projects
Thanks! Learned something new about lookahead!

@manticore-projects
Copy link
Contributor

@manticore-projects Thanks! Learned something new about lookahead!

If you ask me, its rather a shortcoming/problem of JavaCC itself. Your lookaheads were not wrong in my opinion and my syntax should not make any difference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants