April 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:117516] [Ruby master Feature#15554] warn/error passing a block to a method which never use a block
by byroot (Jean Boussier) 15 Apr '24

15 Apr '24

Issue #15554 has been updated by byroot (Jean Boussier). Also to include a positive note, it's definitely pointing at valuable things, e.g. from our test suite: ```ruby SOME_LIST.excluding(things) do |behaviour| test "#... snip #{behaviour.serialize}" do # ...snip end end ``` Here the author clearly wanted to write `SOME_LIST.excluding(things).each do |behaviour|`, but the mistake silently did nothing and this code is essentially dead by accident. ---------------------------------------- Feature #15554: warn/error passing a block to a method which never use a block https://bugs.ruby-lang.org/issues/15554#change-107906 * Author: ko1 (Koichi Sasada) * Status: Closed * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- # Abstract Warn or raise an ArgumentError if block is passed to a method which does not use a block. In other words, detect "block user methods" implicitly and only "block user methods" can accept a block. # Background Sometimes, we pass a block to a method which ignores the passed block accidentally. ``` def my_open(name) open(name) end # user hopes it works as Kernel#open which invokes a block with opened file. my_open(name){|f| important_work_with f } # but simply ignored... ``` To solve this issue, this feature request propose showing warnings or raising an exception on such case. Last developer's meeting, matz proposed `&nil` which declares this method never receive a block. It is explicit, but it is tough to add this `&nil` parameter declaration to all of methods (do you want to add it to `def []=(i, e, &nil)`?). (I agree `&nil` is valuable on some situations) # Spec ## Define "use a block" methods We need to define which method accepts a block and which method does not. * (1) method has a block parameter (`&b`) * (2) method body has `yield' * (3) method body has `super` (ZSUPER in internal terminology) or `super(...)` * (4) method body has singleton method (optional) (1) and (2) is very clear. I need to explain about (3) and (4). (3). `super` (ZSUPER) passes all parameters as arguments. So there is no surprise that which can accept `block`. However `super(...)` also passes a block if no explicit block passing (like `super(){}` or `super(&b)`) are written. I'm not sure we need to continue this strange specification, but to keep compatibility depending this spec, I add this rule. (4). surprisingly, the following code invoke a block: ``` def foo class << Object.new yield end end foo{ p :ok } #=> :ok ``` I'm also not sure we need to keep this spec, but to allow this spec, I added (4) rule. Strictly speaking, it is not required, but we don't keep the link from singleton class ISeq to lexical parent iseq now, so I added it. ## Exceptional cases A method called by `super` doesn`t warn warning even if this method doesn't use a block. The rule (3) can pass blocks easily and there are many methods don`t use a block. So my patch ignores callings by `super`. ## corner cases There are several cases to use block without (1)-(4) rules. ### `Proc.new/proc/lambda` without a block Now it was deprecated in r66772 (commit:9f1fb0a17febc59356d58cef5e98db61a3c03550). Related discussion: [Bug #15539] ### `block_given?` `block_given?` expects block, but I believe we use it with `yield` or a block parameter. If you know the usecase without them, please tell us. ### `yield` in `eval` We can't know `yield` (or (3), (4) rule) in an `eval` evaluating string at calling time. ``` def foo eval('yield`) end foo{} # at calling time, # we can't know the method foo can accept a block or not. ``` So I added a warning to use `yield` in `eval` like that: `test.rb:4: warning: use yield in eval will not be supported in Ruby 3.` Workaround is use a block parameter explicitly. ``` def foo &b eval('b.call') end foo{ p :ok } ``` # Implementation Strategy is: * [compile time] introduce `iseq::has_yield` field and check it if the iseq (or child iseq) contains `yield` (or something) * [calling time] if block is given, check `iseq::has_yield` flag and show warning (or raise an exception) https://gist.github.com/ko1/c9148ad0224bf5befa3cc76ed2220c0b On this patch, now it raises an error to make it easy to detect. It is easy to switch to show the warning. # Evaluation and discussion I tried to avoid ruby's tests. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786 Here is a patch. There are several patterns to avoid warnings. ## tests for `block_given?`, `Proc.new` (and similar) without block Add a dummy block parameter. It is test-specific issue. ## empty `each` Some tests add `each` methods do not `yield`, like: `def each; end`. Maybe test-specific issue, and adding a dummy block parameter. ## Subtyping / duck typing https://github.com/ruby/ruby/blob/c01a5ee85e2d6a7128cccafb143bfa694284ca87/… This `parse` method doesn't use `yield`, but other sub-type's `parse` methods use. ## `super` with `new` method https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… This method override `Class#new` method and introduce a hook with block (yield a block in this hook code). https://github.com/ruby/ruby/blob/trunk/lib/rubygems/package/tar_writer.rb#… In this method, call `super` and it also passing a block. However, called `initialize` doesn't use a block. ## Change robustness This change reduce robustness for API change. `Delegator` requires to support `__getobj__` for client classes. Now `__getobj__` should accept block but most of `__getobj__` clients do not call given block. https://github.com/ruby/ruby/blob/trunk/lib/delegate.rb#L80 This is because of delegator.rb's API change. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… Nobu says calling block is not required (ignoring a block is no problem) so it is not a bug for delegator client classes. ## Found issues. ``` [ 2945/20449] Rinda::TestRingServer#test_do_reply = 0.00 s 1) Error: Rinda::TestRingServer#test_do_reply: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:635:in `test_do_reply' [ 2946/20449] Rinda::TestRingServer#test_do_reply_local = 0.00 s 2) Error: Rinda::TestRingServer#test_do_reply_local: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:657:in `test_do_reply_local' [10024/20449] TestGemRequestSetGemDependencyAPI#test_platform_mswin = 0.01 s 3) Error: TestGemRequestSetGemDependencyAPI#test_platform_mswin: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:655:in `test_platform_mswin' [10025/20449] TestGemRequestSetGemDependencyAPI#test_platforms = 0.01 s 4) Error: TestGemRequestSetGemDependencyAPI#test_platforms: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:711:in `test_platforms' ``` These 4 detection show the problem. `with_timeout` method (used in Rinda test) and `util_set_arch` method (used in Rubygems test) simply ignore the given block. So these tests are simply ignored. I reported them. (https://github.com/rubygems/rubygems/issues/2601) ## raise an error or show a warning? At least, Ruby 2.7 should show warning for this kind of violation with `-w`. How about for Ruby3? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117515] [Ruby master Feature#15554] warn/error passing a block to a method which never use a block
by byroot (Jean Boussier) 15 Apr '24

15 Apr '24

Issue #15554 has been updated by byroot (Jean Boussier). I'm yet to process the warnings uncovered in our app, but to share an early one I think is relevant, from `statsd-instrument`: ```ruby def distribution(key, value = UNSPECIFIED, sample_rate: nil, tags: nil, no_prefix: false, &block) check_block_or_numeric_value(value, &block) check_tags_and_sample_rate(sample_rate, tags) super end private def check_block_or_numeric_value(value) if block_given? raise ArgumentError, "The value argument should not be set when providing a block" unless value == UNSPECIFIED else raise ArgumentError, "The value argument should be a number, got #{value.inspect}" unless value.is_a?(Numeric) end end ``` This is easy to workaround by declaring the block I guess. So I'd expect `block_given?` to qualify as "using the block". But I suppose it's tricky because `block_given?` is just a method like any other for the compiler? ---------------------------------------- Feature #15554: warn/error passing a block to a method which never use a block https://bugs.ruby-lang.org/issues/15554#change-107905 * Author: ko1 (Koichi Sasada) * Status: Closed * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- # Abstract Warn or raise an ArgumentError if block is passed to a method which does not use a block. In other words, detect "block user methods" implicitly and only "block user methods" can accept a block. # Background Sometimes, we pass a block to a method which ignores the passed block accidentally. ``` def my_open(name) open(name) end # user hopes it works as Kernel#open which invokes a block with opened file. my_open(name){|f| important_work_with f } # but simply ignored... ``` To solve this issue, this feature request propose showing warnings or raising an exception on such case. Last developer's meeting, matz proposed `&nil` which declares this method never receive a block. It is explicit, but it is tough to add this `&nil` parameter declaration to all of methods (do you want to add it to `def []=(i, e, &nil)`?). (I agree `&nil` is valuable on some situations) # Spec ## Define "use a block" methods We need to define which method accepts a block and which method does not. * (1) method has a block parameter (`&b`) * (2) method body has `yield' * (3) method body has `super` (ZSUPER in internal terminology) or `super(...)` * (4) method body has singleton method (optional) (1) and (2) is very clear. I need to explain about (3) and (4). (3). `super` (ZSUPER) passes all parameters as arguments. So there is no surprise that which can accept `block`. However `super(...)` also passes a block if no explicit block passing (like `super(){}` or `super(&b)`) are written. I'm not sure we need to continue this strange specification, but to keep compatibility depending this spec, I add this rule. (4). surprisingly, the following code invoke a block: ``` def foo class << Object.new yield end end foo{ p :ok } #=> :ok ``` I'm also not sure we need to keep this spec, but to allow this spec, I added (4) rule. Strictly speaking, it is not required, but we don't keep the link from singleton class ISeq to lexical parent iseq now, so I added it. ## Exceptional cases A method called by `super` doesn`t warn warning even if this method doesn't use a block. The rule (3) can pass blocks easily and there are many methods don`t use a block. So my patch ignores callings by `super`. ## corner cases There are several cases to use block without (1)-(4) rules. ### `Proc.new/proc/lambda` without a block Now it was deprecated in r66772 (commit:9f1fb0a17febc59356d58cef5e98db61a3c03550). Related discussion: [Bug #15539] ### `block_given?` `block_given?` expects block, but I believe we use it with `yield` or a block parameter. If you know the usecase without them, please tell us. ### `yield` in `eval` We can't know `yield` (or (3), (4) rule) in an `eval` evaluating string at calling time. ``` def foo eval('yield`) end foo{} # at calling time, # we can't know the method foo can accept a block or not. ``` So I added a warning to use `yield` in `eval` like that: `test.rb:4: warning: use yield in eval will not be supported in Ruby 3.` Workaround is use a block parameter explicitly. ``` def foo &b eval('b.call') end foo{ p :ok } ``` # Implementation Strategy is: * [compile time] introduce `iseq::has_yield` field and check it if the iseq (or child iseq) contains `yield` (or something) * [calling time] if block is given, check `iseq::has_yield` flag and show warning (or raise an exception) https://gist.github.com/ko1/c9148ad0224bf5befa3cc76ed2220c0b On this patch, now it raises an error to make it easy to detect. It is easy to switch to show the warning. # Evaluation and discussion I tried to avoid ruby's tests. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786 Here is a patch. There are several patterns to avoid warnings. ## tests for `block_given?`, `Proc.new` (and similar) without block Add a dummy block parameter. It is test-specific issue. ## empty `each` Some tests add `each` methods do not `yield`, like: `def each; end`. Maybe test-specific issue, and adding a dummy block parameter. ## Subtyping / duck typing https://github.com/ruby/ruby/blob/c01a5ee85e2d6a7128cccafb143bfa694284ca87/… This `parse` method doesn't use `yield`, but other sub-type's `parse` methods use. ## `super` with `new` method https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… This method override `Class#new` method and introduce a hook with block (yield a block in this hook code). https://github.com/ruby/ruby/blob/trunk/lib/rubygems/package/tar_writer.rb#… In this method, call `super` and it also passing a block. However, called `initialize` doesn't use a block. ## Change robustness This change reduce robustness for API change. `Delegator` requires to support `__getobj__` for client classes. Now `__getobj__` should accept block but most of `__getobj__` clients do not call given block. https://github.com/ruby/ruby/blob/trunk/lib/delegate.rb#L80 This is because of delegator.rb's API change. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… Nobu says calling block is not required (ignoring a block is no problem) so it is not a bug for delegator client classes. ## Found issues. ``` [ 2945/20449] Rinda::TestRingServer#test_do_reply = 0.00 s 1) Error: Rinda::TestRingServer#test_do_reply: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:635:in `test_do_reply' [ 2946/20449] Rinda::TestRingServer#test_do_reply_local = 0.00 s 2) Error: Rinda::TestRingServer#test_do_reply_local: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:657:in `test_do_reply_local' [10024/20449] TestGemRequestSetGemDependencyAPI#test_platform_mswin = 0.01 s 3) Error: TestGemRequestSetGemDependencyAPI#test_platform_mswin: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:655:in `test_platform_mswin' [10025/20449] TestGemRequestSetGemDependencyAPI#test_platforms = 0.01 s 4) Error: TestGemRequestSetGemDependencyAPI#test_platforms: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:711:in `test_platforms' ``` These 4 detection show the problem. `with_timeout` method (used in Rinda test) and `util_set_arch` method (used in Rubygems test) simply ignore the given block. So these tests are simply ignored. I reported them. (https://github.com/rubygems/rubygems/issues/2601) ## raise an error or show a warning? At least, Ruby 2.7 should show warning for this kind of violation with `-w`. How about for Ruby3? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117445] [Ruby master Bug#20411] Kenrel.autoload? behaviour
by gmcgibbon (Gannon McGibbon) 15 Apr '24

15 Apr '24

Issue #20411 has been reported by gmcgibbon (Gannon McGibbon). ---------------------------------------- Bug #20411: Kenrel.autoload? behaviour https://bugs.ruby-lang.org/issues/20411 * Author: gmcgibbon (Gannon McGibbon) * Status: Open * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 👋 I recently tried checking if a top-level constant was autoloaded within a module, and it doesn't seem to work properly when calling `autoload?` from `Kernel`. Here's a simple reproduction script: ``` autoload :A, "a.rb" module B puts Kernel.autoload?(:A) # nil puts Module.autoload?(:A) # a.rb end puts Kernel.autoload?(:A) # a.rb puts Module.autoload?(:A) # a.rb ``` I would expect `Kernel.autoload?` and `Module.autoload?` to behave the same way, and return the path of the autoloaded constant until it is loaded. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:117512] [Ruby master Feature#15554] warn/error passing a block to a method which never use a block
by ko1 (Koichi Sasada) 15 Apr '24

15 Apr '24

Issue #15554 has been updated by ko1 (Koichi Sasada). merged, but please give us your feedback. ---------------------------------------- Feature #15554: warn/error passing a block to a method which never use a block https://bugs.ruby-lang.org/issues/15554#change-107900 * Author: ko1 (Koichi Sasada) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- # Abstract Warn or raise an ArgumentError if block is passed to a method which does not use a block. In other words, detect "block user methods" implicitly and only "block user methods" can accept a block. # Background Sometimes, we pass a block to a method which ignores the passed block accidentally. ``` def my_open(name) open(name) end # user hopes it works as Kernel#open which invokes a block with opened file. my_open(name){|f| important_work_with f } # but simply ignored... ``` To solve this issue, this feature request propose showing warnings or raising an exception on such case. Last developer's meeting, matz proposed `&nil` which declares this method never receive a block. It is explicit, but it is tough to add this `&nil` parameter declaration to all of methods (do you want to add it to `def []=(i, e, &nil)`?). (I agree `&nil` is valuable on some situations) # Spec ## Define "use a block" methods We need to define which method accepts a block and which method does not. * (1) method has a block parameter (`&b`) * (2) method body has `yield' * (3) method body has `super` (ZSUPER in internal terminology) or `super(...)` * (4) method body has singleton method (optional) (1) and (2) is very clear. I need to explain about (3) and (4). (3). `super` (ZSUPER) passes all parameters as arguments. So there is no surprise that which can accept `block`. However `super(...)` also passes a block if no explicit block passing (like `super(){}` or `super(&b)`) are written. I'm not sure we need to continue this strange specification, but to keep compatibility depending this spec, I add this rule. (4). surprisingly, the following code invoke a block: ``` def foo class << Object.new yield end end foo{ p :ok } #=> :ok ``` I'm also not sure we need to keep this spec, but to allow this spec, I added (4) rule. Strictly speaking, it is not required, but we don't keep the link from singleton class ISeq to lexical parent iseq now, so I added it. ## Exceptional cases A method called by `super` doesn`t warn warning even if this method doesn't use a block. The rule (3) can pass blocks easily and there are many methods don`t use a block. So my patch ignores callings by `super`. ## corner cases There are several cases to use block without (1)-(4) rules. ### `Proc.new/proc/lambda` without a block Now it was deprecated in r66772 (commit:9f1fb0a17febc59356d58cef5e98db61a3c03550). Related discussion: [Bug #15539] ### `block_given?` `block_given?` expects block, but I believe we use it with `yield` or a block parameter. If you know the usecase without them, please tell us. ### `yield` in `eval` We can't know `yield` (or (3), (4) rule) in an `eval` evaluating string at calling time. ``` def foo eval('yield`) end foo{} # at calling time, # we can't know the method foo can accept a block or not. ``` So I added a warning to use `yield` in `eval` like that: `test.rb:4: warning: use yield in eval will not be supported in Ruby 3.` Workaround is use a block parameter explicitly. ``` def foo &b eval('b.call') end foo{ p :ok } ``` # Implementation Strategy is: * [compile time] introduce `iseq::has_yield` field and check it if the iseq (or child iseq) contains `yield` (or something) * [calling time] if block is given, check `iseq::has_yield` flag and show warning (or raise an exception) https://gist.github.com/ko1/c9148ad0224bf5befa3cc76ed2220c0b On this patch, now it raises an error to make it easy to detect. It is easy to switch to show the warning. # Evaluation and discussion I tried to avoid ruby's tests. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786 Here is a patch. There are several patterns to avoid warnings. ## tests for `block_given?`, `Proc.new` (and similar) without block Add a dummy block parameter. It is test-specific issue. ## empty `each` Some tests add `each` methods do not `yield`, like: `def each; end`. Maybe test-specific issue, and adding a dummy block parameter. ## Subtyping / duck typing https://github.com/ruby/ruby/blob/c01a5ee85e2d6a7128cccafb143bfa694284ca87/… This `parse` method doesn't use `yield`, but other sub-type's `parse` methods use. ## `super` with `new` method https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… This method override `Class#new` method and introduce a hook with block (yield a block in this hook code). https://github.com/ruby/ruby/blob/trunk/lib/rubygems/package/tar_writer.rb#… In this method, call `super` and it also passing a block. However, called `initialize` doesn't use a block. ## Change robustness This change reduce robustness for API change. `Delegator` requires to support `__getobj__` for client classes. Now `__getobj__` should accept block but most of `__getobj__` clients do not call given block. https://github.com/ruby/ruby/blob/trunk/lib/delegate.rb#L80 This is because of delegator.rb's API change. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… Nobu says calling block is not required (ignoring a block is no problem) so it is not a bug for delegator client classes. ## Found issues. ``` [ 2945/20449] Rinda::TestRingServer#test_do_reply = 0.00 s 1) Error: Rinda::TestRingServer#test_do_reply: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:635:in `test_do_reply' [ 2946/20449] Rinda::TestRingServer#test_do_reply_local = 0.00 s 2) Error: Rinda::TestRingServer#test_do_reply_local: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:657:in `test_do_reply_local' [10024/20449] TestGemRequestSetGemDependencyAPI#test_platform_mswin = 0.01 s 3) Error: TestGemRequestSetGemDependencyAPI#test_platform_mswin: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:655:in `test_platform_mswin' [10025/20449] TestGemRequestSetGemDependencyAPI#test_platforms = 0.01 s 4) Error: TestGemRequestSetGemDependencyAPI#test_platforms: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:711:in `test_platforms' ``` These 4 detection show the problem. `with_timeout` method (used in Rinda test) and `util_set_arch` method (used in Rubygems test) simply ignore the given block. So these tests are simply ignored. I reported them. (https://github.com/rubygems/rubygems/issues/2601) ## raise an error or show a warning? At least, Ruby 2.7 should show warning for this kind of violation with `-w`. How about for Ruby3? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117508] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by alexander-s (Alexander S) 13 Apr '24

13 Apr '24

Issue #18576 has been updated by alexander-s (Alexander S). matz (Yukihiro Matsumoto) wrote in #note-14: > I don't object to the proposal itself. But as @ko1 searched, there are so many gems that compare `Encoding#name` and `ASCII-8BIT`. > So I don't accept the proposal for the sake of compatibility. > > Matz. I've been developing with Ruby for some 10+ years now, and overall I really like the language. However, I also feel that Ruby sometimes seems too focused on being backwards compatible, to a point where it risk hurting the ecosystem. I think this thread is a good example, because it seems like such a small and benign change, yet it's taken several years and lots of back and forth, and in the end the proposed change wasn't even applied(!?). At the same time, several parts of the standard library feels outdated (Net::HTTP for example), and others misplaced (OLE-automation anyone?). On the other hand, new "cool features" are sometimes introduced that I don't really see any value in. For example 'endless ranges' and 'single line end-less method definition'. In short, I share much of Bbatsov's (RuboCop author) sentiment from this article (https://metaredux.com/posts/2019/04/02/ruby-s-creed.html) There is good progress too, I'll happily admit. A few examples that comes to mind are 'keyword params', 'unifying Integer/Fixnum', 'UTF-8 encoding by default', the Prism parser and the focus on performance. All these seemed like sensible improvements, in alignment with development in other modern languages. Others probably have a much better ideas on what old stuff could be improved, but it could be for example: - Remove or deprecate globals - Update the Rubydoc system (many other languages have better documentation systems) - Continue cleaning up the stdlib (some progress has been made in recent Ruby releases, which is good) - Look at popular rules in RuboCop etc, for stuff that people are frequently disabling with linting, and consider deprecating them. - Take it easy with new syntax, ruby already have 'many ways to solve the same problem'. Something like end-less method definition seems like a pointless addition. On our team, we just disabled it with linting on day one. To summarize, obviously backwards compatibility is important. But progress is inevitable and a language that doesn't development at a reasonable pace will eventually stagnate and die. I don't think ruby is there yet, but I'd hate to see it go down that path. I also think think much of this can be managed with deprecation messages and the like. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-107895 * Author: byroot (Jean Boussier) * Status: Open * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117503] [Ruby master Bug#20426] crash on aarch64 linux when using fibers (regression with 3.3)
by froydnj (Nathan Froyd) 12 Apr '24

12 Apr '24

Issue #20426 has been reported by froydnj (Nathan Froyd). ---------------------------------------- Bug #20426: crash on aarch64 linux when using fibers (regression with 3.3) https://bugs.ruby-lang.org/issues/20426 * Author: froydnj (Nathan Froyd) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [aarch64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- We are seeing crashes when using Ruby 3.3 on aarch64-linux and the concurrent-ruby gem. We reduced the crashing testcase to: ``` Fiber.new {}.resume ``` which crashes on 3.3.0: ``` 🍖 froydnj@froydnj-arm64-devbox(graviton):~/ruby-3.3.0$ ~/ruby-3-release/bin/ruby -v ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [aarch64-linux] 🍖 froydnj@froydnj-arm64-devbox(graviton):~/ruby-3.3.0$ ~/ruby-3-release/bin/ruby -e 'Fiber.new {}.resume' -e:1: [BUG] Segmentation fault at 0x000baaaac8a27e30 ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [aarch64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0010 e:000009 CFUNC :resume c:0002 p:0007 s:0006 E:0009f0 EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:0021b0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- -e:1:in `<main>' -e:1:in `resume' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ x0: 0x0000aaaae077e910 x1: 0x0000aaaae08a8110 x2: 0x0000ffffd5d49ff0 x3: 0x0000ffff72bdef60 x4: 0x0000000000000004 x5: 0x0000ffff72bdf018 x6: 0x0000ffff72b5e000 x7: 0x0000ffff72bff000 x18: 0x0000000000000000 x19: 0x0000000000000000 x20: 0x0000000000000000 x21: 0x0000000000000000 x22: 0x0000000000000000 x23: 0x0000000000000000 x24: 0x0000000000000000 x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x0000000000000000 x29: 0x0000000000000000 sp: 0x0000ffff72bdf000 fau: 0x000baaaac8a27e30 -- C level backtrace information ------------------------------------------- Segmentation fault (core dumped) ``` We bisected to this commit, landed shortly before the release: https://github.com/ruby/ruby/commit/d9e5564ccd0e460b7685b786d21cf386b229e2a9 The parent revision: https://github.com/ruby/ruby/commit/9a3c49ee5d6dd3770c21ed8193e7efd64cd81a6e has no problems. Example output: ``` 🍖 froydnj@froydnj-arm64-devbox(graviton):~/ruby$ ~/ruby-3-ok/bin/ruby -e 'Fiber.new {}.resume' 🍖 froydnj@froydnj-arm64-devbox(graviton):~/ruby$ echo $? 0 🍖 froydnj@froydnj-arm64-devbox(graviton):~/ruby$ ~/ruby-3-ok/bin/ruby -v ruby 3.3.0dev (2023-12-22T01:47:36Z v3_3_0~76 9a3c49ee5d) [aarch64-linux] 🍖 froydnj@froydnj-arm64-devbox(graviton):~/ruby$ ~/ruby-3-ko/bin/ruby -e 'Fiber.new {}.resume' -e:1: [BUG] Segmentation fault at 0x0026aaaadfeb5698 ruby 3.3.0dev (2023-12-22T02:30:00Z v3_3_0~75 d9e5564ccd) [aarch64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0010 e:000009 CFUNC :resume c:0002 p:0007 s:0006 E:0023c0 EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:0004d0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- -e:1:in `<main>' -e:1:in `resume' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ x0: 0x0000aaaaefe05910 x1: 0x0000aaaaf00229b0 x2: 0x0000ffffe91efc00 x3: 0x0000ffff6a9fef50 x4: 0x0000000000000004 x5: 0x0000ffff6a9ff018 x6: 0x0000ffff6a97e000 x7: 0x0000ffff6aa1f000 x18: 0x0000000000000000 x19: 0x0000000000000000 x20: 0x0000000000000000 x21: 0x0000000000000000 x22: 0x0000000000000000 x23: 0x0000000000000000 x24: 0x0000000000000000 x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x0000000000000000 x29: 0x0000000000000000 sp: 0x0000ffff6a9ff000 fau: 0x0026aaaadfeb5698 -- C level backtrace information ------------------------------------------- Segmentation fault (core dumped) 🍖 froydnj@froydnj-arm64-devbox(graviton):~/ruby$ ~/ruby-3-ko/bin/ruby -v ruby 3.3.0dev (2023-12-22T02:30:00Z v3_3_0~75 d9e5564ccd) [aarch64-linux] ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117496] [Ruby master Bug#20423] Anonymous block forwarding shouldn't work with ... but it does
by tenderlovemaking (Aaron Patterson) 12 Apr '24

12 Apr '24

Issue #20423 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #20423: Anonymous block forwarding shouldn't work with ... but it does https://bugs.ruby-lang.org/issues/20423 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- According to [this note](https://bugs.ruby-lang.org/issues/11256#note-16), anonymous block forwarding should only be supported when explicitly used in the method signature. For example: ```ruby def foo(&) = bar(&) # OK def foo = bar(&) # NG ``` However, if you use `...` in the method signature, `&` seems to work: ```ruby def foo(...) # bar(*) # Syntax Error # bar(**) # Syntax Error bar(&) # not a syntax error, but I think it should be end ``` I think this should be a syntax error. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117478] [Ruby master Bug#20418] `StringIO#read(..., buffer)` doesn't preserve buffer's encoding
by andrykonchin (Andrew Konchin) 11 Apr '24

11 Apr '24

Issue #20418 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #20418: `StringIO#read(..., buffer)` doesn't preserve buffer's encoding https://bugs.ruby-lang.org/issues/20418 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- IO#read (and similar methods `#read_nonblock`, `#readpartial`, `#sysread`) when called with a `buffer` argument preserve its encoding. But `StringIO#read` doesn't do so: ```ruby file = File.open('test.rb') buffer = "".encode(Encoding::ISO_8859_1) file.read(10, buffer) buffer.encoding # => #<Encoding:ISO-8859-1> ``` ```ruby require 'stringio' io = StringIO.new("# encoding") buffer = "".encode(Encoding::ISO_8859_1) io.read(10, buffer) buffer.encoding # => #<Encoding:ASCII-8BIT> ``` I would expect StringIO's read and similar methods to preserve a buffer's encoding. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117491] [Ruby master Bug#20420] benchmark/gc/redblack.rb license clarification
by vo.x (Vit Ondruch) 11 Apr '24

11 Apr '24

Issue #20420 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20420: benchmark/gc/redblack.rb license clarification https://bugs.ruby-lang.org/issues/20420 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The file states `# License is License is Apache-2` but I wonder how comes. This was imported by commit:git|2802afffd688f4f3dce0492a45dab82bfc80e070 on Jun 20, 2013 and claims to be imported from https://github.com/jruby/rubybench/blob/master/time/bench_red_black.rb . Checking that repo, there is this BSD-2-Clause [LICENSE](https://github.com/jruby/rubybench/blob/master/LICENSE) file introduced on May 21, 2013. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117347] [Ruby master Bug#20397] The nkf license in LEGAL file seems to be obsolete
by vo.x (Vit Ondruch) 11 Apr '24

11 Apr '24

Issue #20397 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20397: The nkf license in LEGAL file seems to be obsolete https://bugs.ruby-lang.org/issues/20397 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The LEGAL file seems to contain [obsolete information](https://github.com/ruby/ruby/blob/a69f0047cb489c136001937442c1… about nkf license. It seems that nkf indeed use such license, but in upstream, it was first changed to [MIT](https://github.com/nurse/nkf/commit/c12280757bfb275d6f9e6b0bf6293a28b0… and then immediately to [zlib](https://github.com/nurse/nkf/commit/2ed3e1c270f1deb9487f7bc7d7586030f… license. Ruby has picked up that change with commit:git|13313688b243882aff7815598ddd9fcbae69bc17 Maybe @naruse can comment about this. -- https://bugs.ruby-lang.org/

2 3