The implications of that are, assuming this proposal is implemented based on start line/column + end line/column (or equivalently, start & end offsets): * No need for `node_id` to implement this feature * This feature works with both `...Eregon (Benoit Daloze)
I thought more about `node_id` and I found at least one case where it is problematic with different versions of Prism. The problem is the `node_id` from the bytecode is computed by the builtin Prism parser used by `prism_compile.c`, whil...Eregon (Benoit Daloze)
For context, how much of this is AI-generated? Is it necessary to be faster than BigDecimal, for which realistic use cases? Could BigDecimal be improved instead? I think the bar for a new numeric core type is very high, and this w...Eregon (Benoit Daloze)
(https://github.com/ruby/strscan/pull/195) * Fixes https://github.com/ruby/strscan/issues/194. * This is a fresh new implementation from scratch, contributed directly to ruby/strscan, under BSD-2-Clause. This was implemented using the s...Eregon (Benoit Daloze)
I had a call with @byroot and I understand better the proposal now. I think the proposal makes sense, but with the small tweaks proposed in https://bugs.ruby-lang.org/issues/21963#note-8 it would completely avoid allocated-but-uniniti...Eregon (Benoit Daloze)
I realized these `init` & `copy` C function hooks could actually be done partly with the proposal in #21852, cc @byroot. (and that solves the issue about needing more space in RClass!) Specifically, the `rb_copy_alloc_func_t` gets the or...Eregon (Benoit Daloze)