-
Notifications
You must be signed in to change notification settings - Fork 56
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
Failed parsing CASE with includeWhitespace: true #117
Comments
Thank you for reporting the issue. I will verify the repro and then update this issue with the finding and ETA for a fix. I will always take PR's. I don't necessarily always consider it an improvement to build against latest however. Can you provide links to the support status for those frameworks and their predecessors, along with your argument on why you think this should be upgraded to the minimum build? There are also options for creating separate proj files for newer frameworks. |
Hi Bruce, thank you again it's a little side exploration for a wider issue, and open source is a gift from you, so please, no ETA. :) I'm trying to figure out if I can parse some of our larger stored procs and turn them into C# and EF. It might not suit my specific use case, because we have a lot of "OUTER APPLY" As for building on |
I'd be interested in helping towards your use case. I also find code generation and such interesting. Recreating OUTER APPLY subqueries with current day EF generation should be doable. Let me know if you get stuck. |
I did a bit more investigation Bruce:
|
#117 Case Expression trailing whitespace
I've verified the repro. I've merged your change into the develop branch for review. Thanks for narrowing in on the issue for me. While I agree that your fix fixes this exact situation, I think the issue is that whitespace after the last argument within any function call is probably not being handled correctly, not specific to just CASE. So I'm trying to verify, and will possibly edit the fix to make more broad, before merging to master. |
I noticed that the problem does not occur parsing argument list that does not have case statements. However argumentListParser has poor error recovery. |
Ok, I'll compare how those react. The other thing that's interesting in your situation is that you've added in a grouping of parens around the CASE. I don't know if that plays into the situation yet or not. |
I refined the test case to a point where it was a trailing space past the CASE that triggered the null reference. There’s some code that is adding NULL to the Tokens list. I noticed there are sections where MoveNext is not checked for success or fail. |
Ya, it's the code that parses arguments, and then tries to access Tokens property from the argument. In this case, argument is null. I agree the logic needs to be hardened, but checking for failure in ParseNext could allow for silently dropped tokens, which worries me more. |
What about if I made the Tokens read only, and provided an AddToken function? I can terminate early and make it easier to troubleshoot. |
I'm not sure I follow how that would solve the problems. It's not that I worry about the token handling themselves, it's more about making sure the cursor stays where we expect it, while not dropping any tokens along the way, as they get passed through all the recursion levels. |
Thank you for this library! I noticed I get a null reference fault here:
stack trace
Incidentally, would you accept a PR to convert this to netstandard20 classlib and netcore60 test project?
The text was updated successfully, but these errors were encountered: