summaryrefslogtreecommitdiff
path: root/tool
diff options
context:
space:
mode:
authorJimmy Miller <jimmy.miller@shopify.com>2022-11-17 23:17:40 -0500
committerGitHub <noreply@github.com>2022-11-17 23:17:40 -0500
commit98e9165b0ac0065b0594c41f7d9f8907e5b1e623 (patch)
tree7fc05be66ec7cd7d2f61bf9e0f4cd630cd497a0a /tool
parentab4379e086d69b13f4446bb0bddd87844650ea1a (diff)
Fix bug involving .send and overwritten methods. (#6752)
@casperisfine reporting a bug in this gist https://gist.github.com/casperisfine/d59e297fba38eb3905a3d7152b9e9350 After investigating I found it was caused by a combination of send and a c_func that we have overwritten in the JIT. For send calls, we need to do some stack manipulation before making the call. Because of the way exits works, we need to do that stack manipulation at the last possible moment. In this case, we weren't doing that stack manipulation at all. Unfortunately, with how the code is structured there isn't a great place to do that stack manipulation for our overridden C funcs. Each overridden C func can return a boolean stating that it shouldn't be used. We would need to do the stack manipulation after all of those checks are done. We could pass a lambda(?) or separate out the logic for "can I run this override" from "now generate the code for it". Since we are coming up on a release, I went with the path of least resistence and just decided to not use these overrides if we are in a send call. We definitely should revist this in the future.
Notes
Notes: Merged-By: maximecb <maximecb@ruby-lang.org>
Diffstat (limited to 'tool')
0 files changed, 0 insertions, 0 deletions