-
Notifications
You must be signed in to change notification settings - Fork 62
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
[v1] Migrate parser to new AST #1626
Conversation
CROSS-ENGINE-REPORT ❌
Testing Details
Result Details
Now FAILING Tests ❌The following 3 test(s) were previously PASSING in BASE but are now FAILING in TARGET: Click here to see
Now IGNORED Tests ❌The complete list can be found in GitHub CI summary, either from Step Summary or in the Artifact. Now Passing Tests180 test(s) were previously failing in BASE (LEGACY-V0.14.8) but now pass in TARGET (EVAL-5E66224). Before merging, confirm they are intended to pass. The complete list can be found in GitHub CI summary, either from Step Summary or in the Artifact. CROSS-COMMIT-REPORT ✅
Testing DetailsResult Details
|
6759a9c
to
7a68858
Compare
import org.partiql.value.PartiQLValueExperimental | ||
import org.partiql.value.int32Value | ||
import org.partiql.value.stringValue | ||
import kotlin.test.assertEquals | ||
|
||
class PartiQLParserBagOpTests { | ||
|
||
private val parser = PartiQLParserDefault() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the partiql-parser tests were modified to use the V1PartiQLParserDefault
. Existing tests other than the DDL tests (since DDL will be added in a later v1 release candidate), still passes with the new parser.
@@ -358,7 +358,7 @@ excludeExprSteps | |||
; | |||
|
|||
fromClause | |||
: FROM tableReference; | |||
: FROM ( tableReference ( COMMA tableReference)* ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made some ANTLR grammar changes to account for the new modeling of FROM
clauses to be better aligned with the SQL1999 BNF definition. See #1579 (comment) for some further context.
public final FromTableRef lhs; | ||
|
||
@NotNull | ||
public final From rhs; | ||
public final FromTableRef rhs; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was an error in the original PR adding the hand-written ASTs. The lhs
and rhs
should have been FromTableRef
s.
8eae47f
to
43584f9
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## v1-migrate-ast-enum-methods #1626 +/- ##
==============================================================
Coverage ? 80.03%
Complexity ? 47
==============================================================
Files ? 19
Lines ? 506
Branches ? 23
==============================================================
Hits ? 405
Misses ? 88
Partials ? 13
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
override fun visitTableCrossJoin(ctx: PartiQLParser.TableCrossJoinContext): FromTableRef = translate(ctx) { | ||
val lhs = visitAs<FromTableRef>(ctx.lhs) | ||
val rhs = visitAs<FromTableRef>(ctx.rhs) | ||
// TODO support other CROSS JOIN variants (e.g. LEFT CROSS JOIN) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The previous ANTLR parser visitor would parse l LEFT CROSS JOIN r
to the AST equivalent of l LEFT JOIN r ON TRUE
. This was mentioned in the PartiQL spec in section 5.4 (https://partiql.org/dql/joins.html#left-join), but I couldn't find it mentioned in the SQL1999 spec. It's not yet clear to me what other JOIN types (e.g. RIGHT
, LEFT OUTER
, INNER
, FULL
, etc.) should support this behavior so I've left it out of the new ANTLR parser visitor for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From offline discussion, will change the ANTLR parsing rules slightly:
- Remove the optional
joinType
before theCROSS JOIN
since that's what is defined in SQL99 spec - Add an explicit rule for
LEFT CROSS JOIN
since that's what is defined in the PartiQL spec - Add TODO linking Vladimir's issue for the other cross join variant investigation -- Explore SQL-consistent syntax for joins #1013
43584f9
to
31d6fd0
Compare
bb30367
to
5db9f62
Compare
Marking as a draft since I need to rebase and incorporate the latest error reporting changes (#1615). |
31d6fd0
to
8751c18
Compare
8751c18
to
da868e1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small comments, otherwise let's get it merged.
partiql-parser/src/main/kotlin/org/partiql/parser/V1PartiQLParserBuilder.kt
Show resolved
Hide resolved
} | ||
} | ||
|
||
companion object { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit no reason for a companion object here unless maybe static?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These were just copied from the existing PartiQLParserDefault
for context. Since the static methods within the companion object are all private, I will just move them out of the companion object.
partiql-parser/src/main/kotlin/org/partiql/parser/internal/V1PartiQLParserDefault.kt
Outdated
Show resolved
Hide resolved
partiql-parser/src/main/kotlin/org/partiql/parser/internal/V1PartiQLParserDefault.kt
Outdated
Show resolved
Hide resolved
partiql-parser/src/main/kotlin/org/partiql/parser/internal/V1PartiQLParserDefault.kt
Outdated
Show resolved
Hide resolved
@OptIn(PartiQLValueExperimental::class) | ||
private class Visitor( | ||
private val tokens: CommonTokenStream, | ||
private val locations: SourceLocations.Mutable, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not for this PR, but I would like to put source locations class under the microscope..
"trail" -> GraphRestrictor.TRAIL() | ||
"acyclic" -> GraphRestrictor.ACYCLIC() | ||
"simple" -> GraphRestrictor.SIMPLE() | ||
else -> throw error(ctx, "Unrecognized pattern restrictor") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious if the message ever propagates beyond here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested locally with a misspelt graph restrictor (i.e. TRAILL
rather than TRAIL
). The message will be part of a syntax PError
with a message captured in the "CAUSE" field -- "org.partiql.parser.PartiQLParserException: Unrecognized pattern restrictor".
ErrorException{error=PError{code=1, severity=ERROR, kind=SYNTAX, location=null, properties={CAUSE=org.partiql.parser.PartiQLParserException: Unrecognized pattern restrictor}}}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't been following the latest PError
developments. Is this the expected behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it's ok, we explicitly state that properties are not semvered
"trail" -> GraphRestrictor.TRAIL() | ||
"acyclic" -> GraphRestrictor.ACYCLIC() | ||
"simple" -> GraphRestrictor.SIMPLE() | ||
else -> throw error(ctx, "Unrecognized pattern restrictor") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it's ok, we explicitly state that properties are not semvered
Relevant Issues
Description
Other Information
Updated Unreleased Section in CHANGELOG: [NO]
Any backward-incompatible changes? [NO]
Any new external dependencies? [NO]
Do your changes comply with the Contributing Guidelines
and Code Style Guidelines? [YES]
License Information
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.