-
Notifications
You must be signed in to change notification settings - Fork 221
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
feat: Add DocComments to PR #4701
Conversation
This is an attempt to get around the complications of managing lexer + parser output, which PRQL#4397 has hit in a few incarnations by just adding comments ('aesthetics') to PL. This very very nearly works -- with chumsky we can create a function that wraps anything that might have a comment, implement a trait on the AST items that contain it, and away we go (though it did require a lot of debugging in the end). This would then be really easy to write back out. I think there's literally a single case where it doesn't work -- where a comment doesn't come directly before or directly after an AST item -- in the final trailing comma of a tuple or array. So tests fail at the moment. Next we need to consider: - Can we workaround that one case? We don't actually care about whether there's a trailing comma, so we could likely hack around it... - Are there actually other cases of this model failing? I know this approach -- of putting aesthetic items into AST -- is not generally favored, and it's really rare that there's even a single case of something not working.
Extracting this from PRQL#4639
Found this while doing the formatting, we don't yet enforce this Possibly there are other areas we don't enforce this sort of thing?
This reverts commit e5a4f26.
For using `dbg!`
This ends up being a pretty big change! We change how we handle new lines, which lets us enforce new lines for some things — previously we were just consuming 0+ new lines almost anywhere, which then means there might not be a new line character remaining to consume when we come to check before an item that requires one. I used lots of tests when trying to fix problems — ended up being a lot, and sometimes kinda complicated. So possibly the tests are a bit duplicated. We could do an effort to reduce the duplication, since there isn't a natural way for tests to reduce in number... But also not that costly to keep them. |
This takes much of the work from #4639 and uses it to push doc comments through to PL.
I'll leave a comment on something I'm stuck on; I can't work out why we get such a bad error message for
from artists #! This is a doc comment
:Expected one of (, [, an identifier, keyword case, keyword internal or {, but didn't find anything before the end.
.This needs lots more tests for doc comments specifically, and lots of clearing up.