Reorganize the Parser module #1581
Conversation
I mostly did this as an exercise to get a general feel of how the Parser implementation is organized. The basics here are that for every top level keyword in Parser::parse_statement I created a new module and moved the corresponding function to that module. Then I spent a few hours checking `find references` and any method that was in a single new module got moved there. Towards the end I started making some arbitary decisions on where functions referenced from multiple modules lived. Some of these seemed obvious, while some were certainly arbitrary. Most of the motivation here was that working on a 13,000 line file was causing my editor to be very not happy. After this happy, the largest module is now src/parser/select.rs which clocks in at 2142 lines. I should note, that the only visible changes are hopefully a few functions that had visibility flipped from private to public because I forgot about pub(crate) when I first started. Other than that, this is purely copy/paste moving of code to new module files.
|
I originally had intentions on spending today trying to see if I couldn't figure out how to help move #1561 forward, but my usual attempt at commenting out the non-clone API made my editor choke on rendering the thousands of error diagnostics that caused. So I figured I'd try splitting up the 13k LoC parser.rs module. This is PR is the result of that. I have no illusions that folks will want to merge this directly, but I figured it was a useful enough exercise that I'd show my work in case there's any desire to start doing something of this nature piecemeal with an eye towards having people that actually know this code base help refine some of my rather arbitrary decisions on the reorganization. I managed to learn a bit about split |
davisp
force-pushed
the
pd/experiment/reorganizing
branch
from
e0934e7 to
8d83ccf
Compare
You can't propose a 26k line diff when CI fails.
davisp
force-pushed
the
pd/experiment/reorganizing
branch
from
8d83ccf to
d1c90b2
Compare
I think breaking the code up into smaller modules sounds like a great idea. Thank you @davisp
Indeed, I think doing this refactoring as a series of PRs would be great. |
I mostly did this as an exercise to get a general feel of how the Parser implementation is organized. The basics here are that for every top level keyword in Parser::parse_statement I created a new module and moved the corresponding function to that module. Then I spent a few hours checking
find referencesand any method that was in a single new module got moved there.Towards the end I started making some arbitary decisions on where functions referenced from multiple modules lived. Some of these seemed obvious, while some were certainly arbitrary.
Most of the motivation here was that working on a 13,000 line file was causing my editor to be very not happy. After this, the largest module is now src/parser/select.rs which clocks in at 2142 lines.
I should note, that the only visible changes are hopefully a few functions that had visibility flipped from private to public because I forgot about pub(crate) when I first started. Other than that, this is purely copy/paste moving of code to new module files.