[pull] master from ruby:master #385
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://github.com/avatars/in/12910?s=60&v=4){kind=small}
Assertions are only enable on debug builds, so it will now check for flags of T_ZOMBIE objects on all builds in GC.verify_internal_consistency.
This adds a check in GC.verify_internal_constency that FL_FINALIZE flags is set if, and only if it is in finalizer_table.
… specific than "any Node" * Fixes ruby/prism#2058 ruby/prism@f3e3310b5e
…ting $CHECK_FIELD_KIND ruby/prism@33e987ba3c
* To avoid duplication. ruby/prism@12e5aae0b4
`test_keyword.rb` caught this issue. Just need to run with `threshold=1`
Recent flaky canary-related CI failures have all happened while trying to fall back. It's unclear what is leaving the canary on the stack and causing gen_send_dynamic() to falsely assume that it should be leaf, and this patch isn't going to help us find the source. One source I found is Array#<< with a frozen array, but it's unclear if that's what's causing the CI failures. I'm somewhat afraid to add a canary check to rb_longjmp() since that might introduce more flaky failures, and maybe ones unrelated to YJIT. See: https://github.com/ruby/ruby/actions/runs/8083502532/job/22086714152 See: https://github.com/ruby/ruby/actions/runs/8066858522/job/22035963315
Displays for each failure which test it actually occurred in. The
output destination follows the --{stdout,stderr}-on-failure option.
Before PIC era, we could assume that the stack is not unwound by imported functions since all imported functions are WASI syscalls and they don't use Asyncify at all. However, PIC binary can import functions from other modules and we cannot guarantee that they won't unwind the stack.
Use an unreleased version of RBS to see if the new commit fixes the `EBADF` error.
The finalizer could trigger a GC, so FL_FINALIZE could get out of sync with the finalizer table.
The finalizer could trigger a GC, which would cause FL_FINALIZE to be out of sync with the finalizer table.
This frees FL_USER0 on both T_MODULE and T_CLASS. Note: prior to this, FL_SINGLETON was never set on T_MODULE, so checking for `FL_SINGLETON` without first checking that `FL_TYPE` was `T_CLASS` was valid. That's no longer the case.
This `st_table` is used to both mark and pin classes defined from the C API. But `vm->mark_object_ary` already does both much more efficiently. Currently a Ruby process starts with 252 rooted classes, which uses `7224B` in an `st_table` or `2016B` in an `RArray`. So a baseline of 5kB saved, but since `mark_object_ary` is preallocated with `1024` slots but only use `405` of them, it's a net `7kB` save. `vm->mark_object_ary` is also being refactored. Prior to this changes, `mark_object_ary` was a regular `RArray`, but since this allows for references to be moved, it was marked a second time from `rb_vm_mark()` to pin these objects. This has the detrimental effect of marking these references on every minors even though it's a mostly append only list. But using a custom TypedData we can save from having to mark all the references on minor GC runs. Addtionally, immediate values are now ignored and not appended to `vm->mark_object_ary` as it's just wasted space.
* WIP getbyte implementation * WIP String#getbyte implementation * Fix whitespace in stats.rs * fix? * Fix whitespace, add comment --------- Co-authored-by: Aaron Patterson <aaron.patterson@shopify.com>
…calls For example, use `.fetch` or `.dig` instead of `[]`, and use `===` instead of `is_a?` for checking types of objects. ruby/prism@548b54915f
Assume that there will never be any time zones with UTC offsets that are subseconds. Historically, UTC offset has only been used down to the second.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )