Introduce using slices instead of locations #3772
Conversation
kddnewton
force-pushed
the
slices
branch
2 times, most recently
from
ae0f2eb to
02d92c7
Compare
Can you explain this a bit? To me it seems most convenient to have it done relatively quickly so that consumers don't have to bother with both variants. Eventually this needs changes in ruby/ruby to compile which will make backporting prism versions a bit annoying, so it would be nice if its not spread across many commits in ruby/ruby I think |
|
(For posterity, linking this to #1566 .) |
Yeah this is a good point. Let's just keep it around for the lifetime of this PR while things get migrated, and then we can squash it all before merge. |
kddnewton
force-pushed
the
slices
branch
5 times, most recently
from
929df4d to
c12168e
Compare
kddnewton
force-pushed
the
slices
branch
5 times, most recently
from
ef86059 to
1714fdc
Compare
|
Just to put this explicitly: not merging this until after Christmas/Ruby 4.0 is released. |
In the C API, we want to use slices instead of locations in the AST. In this case a "slice" is effectively the same thing as the location, expect it is represented using a 32-bit offset and a 32-bit length. This will cut down on half of the space of all of the locations in the AST. Note that from the Ruby/Java/JavaScript side, this is effectively an invisible change. This only impacts the C/Rust side.
In the C API, we want to use slices instead of locations in the AST. In this case a "slice" is effectively the same thing as the location, expect it is represented using a 32-bit offset and a 32-bit length. This will cut down on half of the space of all of the locations in the AST.
I am introducing this as a new field type to ease the migration path, so that this can be merged on its own and then fields can be moved one at a time.
Note that from the Ruby/Java/JavaScript side, this is effectively an invisible change. This only impacts the C/Rust side.
Fixes #1566