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

Issue 473 assertion #476

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

Conversation

ratmice
Copy link
Collaborator

@ratmice ratmice commented Dec 3, 2024

This seems to fix the assert in issue 473, however i'm marking this as draft because
for some reason the spans seem off by one when parsing the examples posted in that issue.
Strangely the spans are fine for the fuzzer minimized reproducer. Should probably also add test cases etc.

I wonder if this could be due to comments?

The other thing is that after fixing the assertion, nimbleparse seems to return to taking forever to parse the file.
I believe that it might be caused by running error recovery, as I did see some error recovery output.

For some reason It isn't clear whether a mention of @mingodad will work, but he may want to try this patch.

Previously the spans of empty productions were lost from the AST.
When a conflict involving an empty production was found a panic would
ensue due to the missing span.
@ltratt
Copy link
Member

ltratt commented Dec 10, 2024

Oops, I missed this one because I wasn't assigned -- sorry!

@ltratt
Copy link
Member

ltratt commented Dec 10, 2024

Dumb question: does this fix the assert with the postgres grammar from the issue?

@ratmice
Copy link
Collaborator Author

ratmice commented Dec 10, 2024

My bad, I seem to consistently mix up assignment vs request review. It does fix it, however I'm not entirely absolutely certain it is totally correct.

I had been thinking that it would be good to do some local testing where I made the prods field non-public and replace it with a prods() function, so I can tell where the field is being used from. From grepping it is too easy to mix up with the prods field of YaccGrammar.

I don't think it is worth including that kind of patch just because of compatibility, but just locally to get a better idea of where this prods field propagates throughout the lib...

@ltratt
Copy link
Member

ltratt commented Dec 11, 2024

I had been thinking that it would be good to do some local testing where I made the prods field non-public and replace it with a prods() function, so I can tell where the field is being used from.

Good idea!

@ltratt
Copy link
Member

ltratt commented Dec 18, 2024

@ratmice I was just wondering if you've had any luck with this?

@ratmice
Copy link
Collaborator Author

ratmice commented Dec 18, 2024

No I'm sorry, I haven't managed to sit down and work on this, or anything yet really. I've taken the month for attempting to see if I can sustain walking 24km a day (hint I cannot, If I really push myself I can still only seem to sustain 22km), So most of my time has been just walking or recovering for the next day. But been keeping at it considering how close to that goal I seem to be... It is inevitable that I'll need a rest day soon, but have a pretty good streak going and when I do it is the first thing on my list. Sorry if that isn't a very satisfying answer.

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