-
Notifications
You must be signed in to change notification settings - Fork 1.8k
fix: Fix parsing of nested tuple field accesses in a cursed way #14084
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
Conversation
Might be worth mentioning here I think, since I've implemented a similar but different approach (though still cursed) here: cynecx@3628848. |
Ah right, I remember this now. At its core these two seem to be the same approach roughly, at least both look terrible :) Fixing up macros is somewhat annoying since you'll need to mutate the correct subtrees (aka we need something like a I'm not sure if we need the hack for anything else though, so a general injection support might be too much? At least I am hopeful that the language doesn't give us more of this kind of ambiguity ... |
Turns out fixing up the inputs for macro expression fragments is a major PITA, so I skipped that for the time being as we aren't regressing on that side, just staying the same. Aside from that, things should just work. Assuming CI passes I'll try to merge it tonight or tomorrow so we can get some nightly testing in. |
Not too fond of the parser changes required to make this work, but it's not like we can do this without any awful hacks so.... |
☀️ Test successful - checks-actions |
This is absolutely terrible but seems to work. Macro fragment parsing comes next.