Issue #19586 has been reported by yahonda (Yasuo Honda).
----------------------------------------
Bug #19586: Rails CI fails since 89bdf6e94cb36567478c509722fe98069402fb8e and RUBY_YJIT_ENABLE=1
https://bugs.ruby-lang.org/issues/19586
* Author: yahonda (Yasuo Honda)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.3.0dev (2023-04-06T15:34:58Z master 89bdf6e94c) [x86_64-linux]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Rails CI against Ruby master with yjit-enabled fails https://buildkite.com/rails/rails/builds/95521#018761e7-3d48-4666-a8cd-d133…
According to git bisect, it is triggered by 89bdf6e94cb36567478c509722fe98069402fb8e
### Steps to reproduce
```
git clone https://github.com/rails/rails
cd rails/activerecord
bundle install
RUBY_YJIT_ENABLE=1 bin/test
```
### Expected behavior
It should pass
### Actual behavior
```ruby
$ ruby -v ; RUBY_YJIT_ENABLE=1 bin/test
ruby 3.3.0dev (2023-04-06T15:34:58Z master 89bdf6e94c) [x86_64-linux]
Using sqlite3
/home/yahonda/src/github.com/rails/rails/activesupport/lib/active_support/code_generator.rb:30:in `instance_method': undefined method `comments_count_will_change!' for module `#<Module:0x00007fb53d644b10>' (NameError)
owner.define_method(name, @cache.instance_method(as))
^^^^^^^^^^^^^^^^
from /home/yahonda/src/github.com/rails/rails/activesupport/lib/active_support/code_generator.rb:30:in `block in apply'
from /home/yahonda/src/github.com/rails/rails/activesupport/lib/active_support/code_generator.rb:29:in `each'
from /home/yahonda/src/github.com/rails/rails/activesupport/lib/active_support/code_generator.rb:29:in `apply'
from /home/yahonda/src/github.com/rails/rails/activesupport/lib/active_support/code_generator.rb:61:in `block in execute'
from /home/yahonda/src/github.com/rails/rails/activesupport/lib/active_support/code_generator.rb:60:in `each_value'
from /home/yahonda/src/github.com/rails/rails/activesupport/lib/active_support/code_generator.rb:60:in `execute'
from /home/yahonda/src/github.com/rails/rails/activesupport/lib/active_support/code_generator.rb:42:in `batch'
from /home/yahonda/src/github.com/rails/rails/activemodel/lib/active_model/attribute_methods.rb:206:in `alias_attribute'
from /home/yahonda/src/github.com/rails/rails/activerecord/test/models/post.rb:28:in `<class:Post>'
from /home/yahonda/src/github.com/rails/rails/activerecord/test/models/post.rb:3:in `<top (required)>'
from <internal:/home/yahonda/.rbenv/versions/trunk/lib/ruby/3.3.0+0/rubygems/core_ext/kernel_require.rb>:37:in `require'
from <internal:/home/yahonda/.rbenv/versions/trunk/lib/ruby/3.3.0+0/rubygems/core_ext/kernel_require.rb>:37:in `require'
from /home/yahonda/src/github.com/rails/rails/activerecord/test/activejob/destroy_association_async_test.rb:11:in `<top (required)>'
from <internal:/home/yahonda/.rbenv/versions/trunk/lib/ruby/3.3.0+0/rubygems/core_ext/kernel_require.rb>:37:in `require'
from <internal:/home/yahonda/.rbenv/versions/trunk/lib/ruby/3.3.0+0/rubygems/core_ext/kernel_require.rb>:37:in `require'
from /home/yahonda/src/github.com/rails/rails/railties/lib/rails/test_unit/runner.rb:50:in `block in load_tests'
from /home/yahonda/src/github.com/rails/rails/railties/lib/rails/test_unit/runner.rb:50:in `each'
from /home/yahonda/src/github.com/rails/rails/railties/lib/rails/test_unit/runner.rb:50:in `load_tests'
from /home/yahonda/src/github.com/rails/rails/railties/lib/rails/test_unit/runner.rb:42:in `run'
from /home/yahonda/src/github.com/rails/rails/activerecord/test/support/tools.rb:37:in `<top (required)>'
from bin/test:11:in `require_relative'
from bin/test:11:in `<main>'
$
```
--
https://bugs.ruby-lang.org/
Issue #19363 has been reported by bkuhlmann (Brooke Kuhlmann).
----------------------------------------
Bug #19363: Fix rb_transient_heap_mark: wrong header (T_STRUCT) segfault
https://bugs.ruby-lang.org/issues/19363
* Author: bkuhlmann (Brooke Kuhlmann)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22.2.0]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
## Overview
Hello. 👋 I'm hitting an issue where my build is constantly failing with a segfault. The following is a snippet taken from my local machine with YJIT enabled (see attachments for details):
```
/Users/bkuhlmann/.cache/frum/versions/3.2.0/lib/ruby/gems/3.2.0/gems/puma-6.0.2/lib/puma/runner.rb: [BUG] rb_transient_heap_mark: wrong header, T_STRUCT (0x0000000109ea98a0)
ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22.2.0]
```
The closest issue I could find that might be related to this issue (but not sure) is this issue: #15358.
## Steps to Recreate
You should be able to quickly recreate this issue via these steps:
- Download/clone my [Hemo](https://github.com/bkuhlmann/hemo) project.
- Run the setup steps.
- Run the test suite by running `bin/rspec`.
If you need an example of the same segfault (but not on my macOS machine), you can see the same segfault via my [Circle CI Build](https://app.circleci.com/pipelines/github/bkuhlmann/hemo/11/workflow…. My Circle CI build is using my [Docker Alpine Linux Ruby](https://www.alchemists.io/projects/docker-alpine-ruby) image which might be of interest as well. This Docker image is also built with YJIT enabled.
Interestingly, is if you were to run the test suite with `bin/guard` instead of `bin/rspec` then the segfault doesn't occur.
## Environment
```
ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22.2.0]
1.43.0 (using Parser 3.2.0.0, rubocop-ast 1.24.1, running on ruby 3.2.0) [arm64-darwin22.2.0]
- rubocop-performance 1.15.2
- rubocop-rake 0.6.0
- rubocop-rspec 2.18.1
- rubocop-sequel 0.3.4
- rubocop-thread_safety 0.4.4
```
---Files--------------------------------
segfault.txt (237 KB)
ruby-2023-01-21-113841.ips (19.6 KB)
--
https://bugs.ruby-lang.org/
Issue #19584 has been reported by peterzhu2118 (Peter Zhu).
----------------------------------------
Bug #19584: Crash in rb_gc_register_address
https://bugs.ruby-lang.org/issues/19584
* Author: peterzhu2118 (Peter Zhu)
* Status: Open
* Priority: Normal
* Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED
----------------------------------------
GitHub PR: https://github.com/ruby/ruby/pull/7670
Some C extensions pass a pointer to a global variable to rb_gc_register_address. However, if a GC is triggered inside of rb_gc_register_address, then the object could get swept since it does not exist on the stack.
--
https://bugs.ruby-lang.org/
Issue #19583 has been reported by hurricup (Alexandr Evstigneev).
----------------------------------------
Bug #19583: Unary minus inconsistency when used with variables and literals
https://bugs.ruby-lang.org/issues/19583
* Author: hurricup (Alexandr Evstigneev)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
This feels a bit inconsistent and I could not find an explanation.
This is fine and `-` has higher precedence than `.`
```
-2.upto 0 do |arg|
puts arg
end
```
But this is not working, won't even compile (requires parens):
```
var = 2
-var.upto 0 do |arg|
puts arg
end
```
I presume that in the first example there is no unary minus operation, just negative literal.
--
https://bugs.ruby-lang.org/
Issue #19581 has been reported by mliu404 (Nikola Liu).
----------------------------------------
Misc #19581: Will Openssl 1.1.x fully support for Ruby3.1 throught the life time of Ruby3.1?
https://bugs.ruby-lang.org/issues/19581
* Author: mliu404 (Nikola Liu)
* Status: Open
* Priority: Normal
----------------------------------------
Currently Ruby3.1 require openSSL 1.1.x / 3.0.x to build rubyGem. Does the requirement for openSSL will be the same for all future minor version of Ruby3.1 ?
--
https://bugs.ruby-lang.org/
Issue #18368 has been updated by Dan0042 (Daniel DeLorme).
Ah, from https://github.com/ruby/dev-meeting-log/blob/master/2022/DevMeeting-2022-01…
> matz: we should not modify the behavior when the receiver is a String
I take that to mean Matz prefers not breaking compatibility.
----------------------------------------
Feature #18368: Range#step semantics for non-Numeric ranges
https://bugs.ruby-lang.org/issues/18368#change-102666
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I am sorry if the question had already been discussed, can't find the relevant topic.
"Intuitively", this looks (for me) like a meaningful statement:
```ruby
(Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a
# ^^^^^ or just 24*60*60
```
Unfortunately, it doesn't work with "TypeError (can't iterate from Time)".
Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer:
```ruby
('a'..'z').step(3).first(5)
# => ["a", "d", "g", "j", "m"]
```
The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected:
```ruby
(1.0..7.0).step(0.3).first(5)
# => [1.0, 1.3, 1.6, 1.9, 2.2]
```
(Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.)
Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!)
Hence, two questions:
* Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild
* If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`?
**UPD:** More examples of useful behavior (it is NOT only about core `Time` class):
```ruby
require 'active_support/all'
(1.minute..20.minutes).step(2.minutes).to_a
#=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes]
require 'tod'
(Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a
#=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>]
require 'matrix'
(Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3)
#=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]]
require 'unitwise'
(Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s)
#=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"]
```
**UPD:** Responding to discussion points:
**Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation.
**A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal.
**Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`)
**A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival).
The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior:
1. Easy to explain and announce
2. Require no other code changes to immediately become useful
3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2
All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`.
--
https://bugs.ruby-lang.org/
Issue #18368 has been updated by zverok (Victor Shepelev).
@Dan0042 I value backwards compatibility a lot (I mentioned it in original ticket).
I though believe that in _this_ particular case the old behaviour for non-numeric ranges is so weird that
1. Very small amount of code, if any, would be broken
2. The error would be very clear
3. Preserving both behaviours just for strings would be very hard to explain in hindsight and will affect language's quality and learnability.
----------------------------------------
Feature #18368: Range#step semantics for non-Numeric ranges
https://bugs.ruby-lang.org/issues/18368#change-102665
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I am sorry if the question had already been discussed, can't find the relevant topic.
"Intuitively", this looks (for me) like a meaningful statement:
```ruby
(Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a
# ^^^^^ or just 24*60*60
```
Unfortunately, it doesn't work with "TypeError (can't iterate from Time)".
Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer:
```ruby
('a'..'z').step(3).first(5)
# => ["a", "d", "g", "j", "m"]
```
The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected:
```ruby
(1.0..7.0).step(0.3).first(5)
# => [1.0, 1.3, 1.6, 1.9, 2.2]
```
(Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.)
Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!)
Hence, two questions:
* Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild
* If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`?
**UPD:** More examples of useful behavior (it is NOT only about core `Time` class):
```ruby
require 'active_support/all'
(1.minute..20.minutes).step(2.minutes).to_a
#=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes]
require 'tod'
(Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a
#=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>]
require 'matrix'
(Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3)
#=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]]
require 'unitwise'
(Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s)
#=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"]
```
**UPD:** Responding to discussion points:
**Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation.
**A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal.
**Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`)
**A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival).
The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior:
1. Easy to explain and announce
2. Require no other code changes to immediately become useful
3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2
All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`.
--
https://bugs.ruby-lang.org/
Issue #18368 has been updated by Dan0042 (Daniel DeLorme).
I guess we just have different values regarding backward compatibility. Your arguments are not false, but to me they have a value several orders of magnitude below compatibility. It doesn't need to be a "very common" idiom, it just needs to be used by a few people, who discover their code breaks upon upgrade, and after a few times of getting angry due to breakage decide to throw the towel and never again choose ruby for a new project.
I'm not sure if @Matz meant "yes, it's ok to break compatibility" or "yes, it's ok since it doesn't break compatibility".
----------------------------------------
Feature #18368: Range#step semantics for non-Numeric ranges
https://bugs.ruby-lang.org/issues/18368#change-102664
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I am sorry if the question had already been discussed, can't find the relevant topic.
"Intuitively", this looks (for me) like a meaningful statement:
```ruby
(Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a
# ^^^^^ or just 24*60*60
```
Unfortunately, it doesn't work with "TypeError (can't iterate from Time)".
Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer:
```ruby
('a'..'z').step(3).first(5)
# => ["a", "d", "g", "j", "m"]
```
The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected:
```ruby
(1.0..7.0).step(0.3).first(5)
# => [1.0, 1.3, 1.6, 1.9, 2.2]
```
(Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.)
Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!)
Hence, two questions:
* Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild
* If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`?
**UPD:** More examples of useful behavior (it is NOT only about core `Time` class):
```ruby
require 'active_support/all'
(1.minute..20.minutes).step(2.minutes).to_a
#=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes]
require 'tod'
(Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a
#=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>]
require 'matrix'
(Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3)
#=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]]
require 'unitwise'
(Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s)
#=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"]
```
**UPD:** Responding to discussion points:
**Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation.
**A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal.
**Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`)
**A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival).
The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior:
1. Easy to explain and announce
2. Require no other code changes to immediately become useful
3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2
All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`.
--
https://bugs.ruby-lang.org/