-
Notifications
You must be signed in to change notification settings - Fork 19
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
Introduce BadNode
and MultiError
#230
Conversation
393232a
to
d14fe1b
Compare
l := p.Lexer.Clone() | ||
defer func() { | ||
if r := recover(); r != nil { | ||
// When parsing is failed on tryParseHint or tryParseWith, the result of these methods are discarded |
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 have concerning discarding hints and CTEs means input statement can't be recovered by SQL()
. I think it don't satisfy users needs. I believe that users expect parse-unparse is safe operation even if BadNode
.
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.
Parsing results are discarded, but the contents (tokens) are preserved. Therefore, your concern is not a problem.
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 mean, parse-unparse is still safe after this PR.
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.
Thank you for explanation.
I understood all handleParse*Error
will eat tokens between l.Token.Pos
and their stop position.
ec86532
to
20e2973
Compare
I feel like this specification hasn't been fully discussed, and I have some personal concerns about the current behavior. As a memefish contributor, it's clear that this change introduces new complexity. I believe there should be a strong enough benefit to justify introducing this complexity. Furthermore, as a developer of tools that use memefish, I don't find the current specification sufficiently useful. Because Badnode implements too many interfaces, it cannot be used effectively for type assertions. In fact, it has the potential to introduce bugs, so I would likely choose to avoid using BadNode altogether. My suggestion is to break down the Node into smaller, more specific types for implementing interfaces. If we did this, it would be genuinely more useful than before this PR, and I might actually use it going forward. PoC branch: feature/bad-node...apstndb:memefish:feature/poc-bad-nodes Typical code with my usecase |
Yeah, I may prefer feature/bad-node HEAD: https://go.dev/play/p/P0SgHl6vUGg |
#230 (comment) Co-Authored-By: apstndb <[email protected]>
20e2973
to
2c0d969
Compare
#230 (comment) Co-Authored-By: apstndb <[email protected]>
8dbc8c8
to
748f3e0
Compare
BadNode
and ErrorList
BadNode
and MultiError
#230 (comment) Co-Authored-By: apstndb <[email protected]>
c162227
to
3954dc9
Compare
This PR introduces
BadNode
andMultiError
.BadNode
is a placeholder node for a source fragment containing syntax errors.MultiError
is an error consisting of a list of*memefish.Error
.Example: