Issue #19427 has been reported by andrykonchin (Andrew Konchin).
----------------------------------------
Bug #19427: Marshal.load(source, freeze: true) doesn't freeze in some cases
https://bugs.ruby-lang.org/issues/19427
* Author: andrykonchin (Andrew Konchin)
* Status: Open
* Priority: Normal
* ruby -v: 3.1
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
I've noticed that the `freeze` option doesn't work in the following cases:
- when dumped object extends a module
- when dumped object responds to `#marshal_dump` and `#marshal_load` methods
- when dumped object responds to `#_dump` method
Is it expected behaviour or a known issue?
Examples:
```ruby
module M
end
object = Object.new
object.extend(M)
object = Marshal.load(Marshal.dump(object), freeze: true)
object.frozen? # => false
```
```ruby
class UserMarshal
attr_accessor :data
def initialize
@data = 'stuff'
end
def marshal_dump() :data end
def marshal_load(data) @data = data end
end
object = Marshal.load(Marshal.dump(UserMarshal.new), freeze: true)
object.frozen? # => false
```
```ruby
class UserDefined
attr_reader :a, :b
def initialize
@a = 'stuff'
@b = @a
end
def _dump(depth)
Marshal.dump [:stuff, :stuff]
end
def self._load(data)
a, b = Marshal.load data
obj = allocate
obj.instance_variable_set :@a, a
obj.instance_variable_set :@b, b
obj
end
end
```
--
https://bugs.ruby-lang.org/
Issue #19530 has been reported by dstosik (David Stosik).
----------------------------------------
Bug #19530: `Array#sum` and `Enumerable#sum` sometimes show different behaviours
https://bugs.ruby-lang.org/issues/19530
* Author: dstosik (David Stosik)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [arm64-darwin22]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Hi everyone. 👋🏻
We recently discovered that `Array#sum` and `Enumerable#sum` will output different results in some edge cases.
Here's the smallest script I managed to write to reproduce the issue:
``` ruby
class Money
def initialize(amount)
@amount = amount.to_f
end
def +(other)
self.class.new(@amount + other.to_f)
end
def to_f
@amount
end
end
p [7.0].each.sum(Money.new(0)).class #=> Money
p [7.0] .sum(Money.new(0)).class #=> Float 💥
```
I understand that it is expected that `#sum` may not honor custom definitions of the `#+` method (particularly when the summed values are `Float`).
However, I would like to bring your attention to the fact that, in the example above, calling `#sum` on an `Array` of `Float` values and calling `#sum` on an `Enumerable` that yields the same `Float` values will return results of different types.
I've reproduced the same behaviour with multiple versions of Ruby going from 2.6.5 to 3.2.1.
Ideally, I would expect `[7.0].sum(Money.new(0))` to return a `Money` object identical to the one returned by `[7.0].each.sum(Money.new(0))`.
I think it would make sense if at least they returned an identical value (even if it is a `Float`).
--
https://bugs.ruby-lang.org/
Issue #19840 has been reported by FlickGradley (Nick Bradley).
----------------------------------------
Feature #19840: [Proposal] Expand Find pattern to Multiple Find
https://bugs.ruby-lang.org/issues/19840
* Author: FlickGradley (Nick Bradley)
* Status: Open
* Priority: Normal
----------------------------------------
Hello! I love Ruby's pattern matching features. I would like to propose an expansion of the Find pattern which allows the selection of multiple matching elements of an array.
I often find myself dealing with data like this:
``` ruby
{ results: [{ id: 1, name: "foo" }, { id: 2, name: "bar" }, ... ] }
```
My problem is that I need to retrieve all the `id` values from the nested array of hashes, and I don't know how many there will be in advance.
It seems that the Find pattern could be expanded from allowing `pattern` (matching a single element) to `*pattern`. Examples:
``` ruby
# Base case
case { results: [{ id: 1, name: "foo" }, { id: 2, name: "bar" }] }
in results: [*{ id: ids }]
"matched: #{ids}"
else
"not matched"
end
#=> matched: [1, 2]
# With * at the end (rest of args) - same result
case { results: [{ id: 1, name: "foo" }, { id: 2, name: "bar" }] }
in results: [*{ id: ids }, *]
"matched: #{ids}"
else
"not matched"
end
#=> matched: [1, 2]
# When one element doesn't match and there is no *rest
case { results: [{ name: "foo" }, { id: 2, name: "bar" }] }
in results: [*{ id: ids }]
"matched: #{ids}"
else
"not matched"
end
#=> not matched
```
Similarly, `*Constant` could work to pull out types with an As pattern:
``` ruby
case [1, 2, 3, "string"]
in *Integer => nums, *
"matched: #{nums}"
else
"not matched"
end
#=> matched: [1, 2, 3]
```
Other patterns would work in the same way. Essentially, this expands the concept of `*` in pattern matching to mean "a variable number of `things matching subpattern`". Today, the only pattern supported by `*` is a variable binding - but it could be any of the other subpatterns as well.
This proposal does imply that this would work:
``` ruby
a = 2
[1, 2, 2, 3] in [*, *^a, *]
#=> true
```
To me, the `*` represents the variable number of matches, so the syntax makes intuitive sense. But others may have different opinions about `*^` being adjacent.
It may also imply this would work, though we could restrict the number of non-variable patterns (in other words, patterns that have the possibility of not matching) to 1 per Array so that this isn't possible.. I'm not sure something like this would be useful or clear.
``` ruby
a = 2
[1, 2, "hello", "ruby"] in [*Integer, *String]
#=> true
```
This feature feels like the missing piece of the Find pattern to me - I often want to "Find Multiple". If others agree, I would be happy to contribute by working on this feature and creating a pull request.
--
https://bugs.ruby-lang.org/
Issue #19920 has been reported by Eregon (Benoit Daloze).
----------------------------------------
Bug #19920: Ruby 3.1 fails to build with --enable-shared on macos-arm64: is an incompatible architecture (have 'arm64', need '')
https://bugs.ruby-lang.org/issues/19920
* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
See https://github.com/ruby/ruby-builder/actions/runs/6494296018/job/1763696879…
```
installing bundled gems: /Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/ruby/gems/3.1.0
minitest 5.15.0
power_assert 2.0.1
rake 13.0.6
test-unit 3.5.3
rexml 3.2.5
rss 0.2.9
net-ftp 0.1.3
net-imap 0.2.3
net-pop 0.1.1
net-smtp 0.3.1
matrix 0.4.2
prime 0.1.2
rbs 2.7.0
Building native extensions. This could take a while...
/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:102:in `run': ERROR: Failed to build gem native extension. (Gem::Ext::BuildError)
current directory: /Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/ruby/gems/3.1.0/gems/rbs-2.7.0/ext/rbs_extension
/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/bin/ruby -I /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib extconf.rb
checking for whether -std=c99 is accepted as CFLAGS... *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers. Check the mkmf.log file for more details. You may
need configuration options.
Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/bin/$(RUBY_BASE_NAME)
/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:490:in `try_do': The compiler failed to generate an executable file. (RuntimeError)
You have to install development tools first.
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:616:in `block in try_compile'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:563:in `with_werror'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:616:in `try_compile'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:680:in `try_cflags'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:1025:in `block (2 levels) in append_cflags'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:989:in `block in checking_for'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:354:in `block (2 levels) in postpone'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:324:in `open'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:354:in `block in postpone'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:324:in `open'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:350:in `postpone'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:988:in `checking_for'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:1024:in `block in append_cflags'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:1023:in `each'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/mkmf.rb:1023:in `append_cflags'
from extconf.rb:3:in `<main>'
To see why this extension failed to compile, please check the mkmf.log which can be found here:
/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/ruby/gems/3.1.0/extensions/arm64-darwin-22/3.1.0/rbs-2.7.0/mkmf.log
extconf failed, exit code 1
Gem files will remain installed in /Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/ruby/gems/3.1.0/gems/rbs-2.7.0 for inspection.
Results logged to /Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/ruby/gems/3.1.0/extensions/arm64-darwin-22/3.1.0/rbs-2.7.0/gem_make.out
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/ext_conf_builder.rb:28:in `build'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:171:in `build_extension'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:205:in `block in build_extensions'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:202:in `each'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:202:in `build_extensions'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/installer.rb:843:in `build_extensions'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/installer.rb:326:in `install'
from ./tool/rbinstall.rb:899:in `block in install'
from ./tool/rbinstall.rb:713:in `no_write'
from ./tool/rbinstall.rb:899:in `install'
from ./tool/rbinstall.rb:1063:in `block (2 levels) in <main>'
from ./tool/rbinstall.rb:1044:in `foreach'
from ./tool/rbinstall.rb:1044:in `block in <main>'
from ./tool/rbinstall.rb:1119:in `block in <main>'
from ./tool/rbinstall.rb:1116:in `each'
from ./tool/rbinstall.rb:1116:in `<main>'
/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:102:in `run': extconf failed, exit code 1 (Gem::InstallError)
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/ext_conf_builder.rb:28:in `build'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:171:in `build_extension'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:205:in `block in build_extensions'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:202:in `each'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/ext/builder.rb:202:in `build_extensions'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/installer.rb:843:in `build_extensions'
from /private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/lib/rubygems/installer.rb:326:in `install'
from ./tool/rbinstall.rb:899:in `block in install'
from ./tool/rbinstall.rb:713:in `no_write'
from ./tool/rbinstall.rb:899:in `install'
from ./tool/rbinstall.rb:1063:in `block (2 levels) in <main>'
from ./tool/rbinstall.rb:1044:in `foreach'
from ./tool/rbinstall.rb:1044:in `block in <main>'
from ./tool/rbinstall.rb:1119:in `block in <main>'
from ./tool/rbinstall.rb:1116:in `each'
from ./tool/rbinstall.rb:1116:in `<main>'
make: *** [do-install-nodoc] Error 1
BUILD FAILED (macOS 13.6 using ruby-build 20231012)
```
And the mkmf.log:
```
DYLD_FALLBACK_LIBRARY_PATH=.:/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib:/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4 "clang -o conftest -I/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/include/ruby-3.1.0/arm64-darwin22 -I/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/include/ruby-3.1.0/ruby/backward -I/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/include/ruby-3.1.0 -I. -I/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/include -DENABLE_PATH_CHECK=0 -I/opt/homebrew/opt/gmp/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wdeprecated-declarations -Wdivision-by-zero -Wimplicit-function-declaration -Wimplicit-int -Wmisleading-indentation -Wpointer-arith -Wshorten-64-to-32 -Wwrite-strings -Wold-style-definition -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wunused-variable -Wextra-tokens -Wundef -fno-common -pipe conftest.c -L. -L/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib -L. -L/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib -fstack-protector-strong -L/opt/homebrew/opt/gmp/lib -lruby.3.1 "
dyld[47952]: terminating because inserted dylib '/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' could not be loaded: tried: '/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), '/System/Volumes/Preboot/Cryptexes/OS/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' (no such file), '/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), './libruby.3.1.dylib' (no such file), '/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/libruby.3.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need ''))
dyld[47952]: tried: '/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), '/System/Volumes/Preboot/Cryptexes/OS/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' (no such file), '/private/var/folders/df/1dm_t2rx0054k7bw1g_7nyl80000gn/T/ruby-build.20231012101401.55539.tTlMYN/ruby-3.1.4/libruby.3.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), './libruby.3.1.dylib' (no such file), '/Users/runner/hostedtoolcache/Ruby/3.1.4/arm64/lib/libruby.3.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need ''))
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: int main(int argc, char **argv)
4: {
5: return !!argv[argc];
6: }
/* end */
```
I believe this bug has nothing to do with ruby-build except that ruby-build does `--enable-shared` by default.
A known workaround is to use `--disable-shared`: https://github.com/rbenv/ruby-build/discussions/1961#discussioncomment-4031…
Lots of other people met the same or similar issue as discussed there.
Also discussed in https://github.com/ruby/rbs/issues/877
It would be nice if this could be fixed on the 3.1 branch.
--
https://bugs.ruby-lang.org/
Issue #19979 has been reported by ufuk (Ufuk Kayserilioglu).
----------------------------------------
Feature #19979: Allow methods to declare that they don't accept a block via `&nil`
https://bugs.ruby-lang.org/issues/19979
* Author: ufuk (Ufuk Kayserilioglu)
* Status: Open
* Priority: Normal
----------------------------------------
## Abstract
This feature proposes new syntax to allow methods to explicitly declare that they don't accept blocks, and makes passing of a block to such methods an error.
## Background
In #15554, it was proposed to automatically detect methods that do not use the block passed to them, and to error if a block was passed to such methods. As far as I can tell, it was later on closed since #10499 solved a large part of the problem.
That proposal has, as part of the dev meeting discussion, a proposal from @matz to allow methods to use `&nil` to explicitly declare that they don't accept a block. At the time, the proposal was trying to solve a bigger problem, so this sub-proposal was never considered seriously. However, notes in the proposal say:
> 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)
This proposal extracts that sub-proposal to make this a new language feature.
## Proposal
In Ruby, it is always valid for the caller to pass a block to a method call, even if the callee is not expecting a block to be passed. This leads to subtle user errors, where the author of some code assumes a method call uses a block, but the block passed to the method call is silently ignored.
The proposal is to introduce `&nil` at method declaration sites to mean "This method does not accept a block". This is symmetric to the ability to pass `&nil` at call sites to mean "I am not passing a block to this method call", which is sometimes useful when making `super` calls (since blocks are always implicitly passed).
Explicitly, the proposal is to make the following behaviour be a part of Ruby:
```ruby
def find(item = nil, &nil)
# some implementation that doesn't call `yield` or `block_given?`
end
find { |i| i == 42 }
# => ArgumentError: passing block to the method `find' that does not accept a block.
```
## Implementation
I assume the implementation would be a grammar change to make `&nil` valid at method declaration sites, as well as raising an `ArgumentError` for methods that are called with a block but are declared with `&nil`.
## Evaluation
Since I don't have an implementation, I can't make a proper evaluation of the feature proposal. However, I would expect the language changes to be minimal with no runtime costs for methods that don't use the `&nil` syntax.
## Discussion
This proposal has much smaller scope than #15554 so that the Ruby language can start giving library authors the ability to explicitly mark their methods as not accepting a block. This is fully backward compatible, since it is an opt-in behaviour and not an opt-out one.
Future directions after this feature proposal could be a way to signal to the VM that any method in a file that doesn't explicitly use `yield`/`block_given?` or explicitly declared a block parameter should be treated as not accepting a block. This can be done via some kind of pragma similar to `frozen_string_literal`, or through other means. However, such future directions are beyond the scope of this proposal.
## Summary
Adding the ability for methods to declare that they don't accept a block will make writing code against such methods safer and more resilient, and will prevent silently ignored behaviour that is often hard to catch or troubleshoot.
--
https://bugs.ruby-lang.org/
Issue #20094 has been reported by sisyphus_cg (Sisyphus CG).
----------------------------------------
Bug #20094: Inline while loop behavior changed unexpectedly in 3.3.0
https://bugs.ruby-lang.org/issues/20094
* Author: sisyphus_cg (Sisyphus CG)
* Status: Open
* Priority: Normal
* ruby -v: 3.3.0
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
The behavior of the inline while loop has changed in 3.3.0. This unexpectedly broke my code and I couldn't find anything in the changelog about it so reporting it as a bug.
In ruby <= 3.2:
``` ruby
(p 1) while false # nothing
(p 1; p 2) while false # nothing
```
In ruby 3.3:
``` ruby
(p 1) while false # 1
(p 1; p 2) while false # 1 2
```
Essentially, if the left hand side looks like a statement, now it is treated as a do-while loop. In ruby 3.2 and less this only happened with explicit use of `begin` and `end`.
--
https://bugs.ruby-lang.org/
Issue #20089 has been reported by rmosolgo (Robert Mosolgo).
----------------------------------------
Bug #20089: Fiber#kill transfers to root fiber
https://bugs.ruby-lang.org/issues/20089
* Author: rmosolgo (Robert Mosolgo)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-darwin22]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
I was hoping to use `Fiber#kill` to clean up formerly `.transfer`-d Fibers and work around https://bugs.ruby-lang.org/issues/20081, but I found that `Fiber#kill` has a similar control flow jump behavior. Is this on purpose, or a bug?
Here's a script to test the behavior:
```ruby
manager = Fiber.new do
worker = Fiber.new do
puts "2. Begin Worker"
manager.transfer
puts "This should never print -- killed"
end
puts "1. Transfer to Worker"
worker.transfer
puts "3. Killing Worker"
worker.kill
puts "4. Finished manager"
end
manager.transfer
puts "5. Finished script"
```
I expected items `1` through `5` to be printed in order, but in fact, `4` is never printed:
```
$ ruby fiber_transfer_test.rb
1. Transfer to Worker
2. Begin Worker
3. Killing Worker
5. Finished script
```
It seems like `worker.kill` is transferring control to the top-level fiber instead of giving it back to `manager`.
I also tried having the thread kill _itself_, hoping it would return to the fiber that originally `.transfer`ed to it, but it also seems to jump out:
```ruby
manager = Fiber.new do
worker = Fiber.new do
puts "2. Begin Worker"
manager.transfer
Fiber.current.kill
puts "This should never print -- killed"
end
puts "1. Transfer to Worker"
worker.transfer
puts "3. Killing Worker"
worker.transfer
puts "4. Finished manager"
end
manager.transfer
puts "5. Finished script"
```
Prints:
```
1. Transfer to Worker
2. Begin Worker
3. Killing Worker
5. Finished script
```
--
https://bugs.ruby-lang.org/
Issue #19266 has been reported by gareth (Gareth Adams).
----------------------------------------
Bug #19266: URI::Generic should use URI::RFC3986_PARSER instead of URI::DEFAULT_PARSER
https://bugs.ruby-lang.org/issues/19266
* Author: gareth (Gareth Adams)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [arm64-darwin21]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
In June 2014, [`uri/common` was updated][1] to introduce a RFC3986-compliant parser (`URI::RFC3986_PARSER`) as an alternative to the previous RFC2396 parser, and common methods like `URI()` were updated to use that new parser by default. The only methods in `common` not updated were [`URI.extract` and `URI.regexp`][2] which are marked as obsolete. (The old parser was kept in the `DEFAULT_PARSER` constant despite it not being the default for those methods, presumably for backward compatibility.)
However, similar [methods called on `URI::Generic`][3] were never updated to use this new parser. This means that methods like `URI::Generic.build` fail when given input that succeeds normally, and this also affects subclasses like URI::HTTP:
```
$ pry -r uri -r uri/common -r uri/generic
[1] pry(main)> URI::Generic.build(host: "underscore_host.example")
URI::InvalidComponentError: bad component(expected host component): underscore_host.example
from /Users/gareth/.asdf/installs/ruby/3.1.3/lib/ruby/3.1.0/uri/generic.rb:591:in `check_host'
[2] pry(main)> URI::HTTP.build(host: "underscore_host.example")
URI::InvalidComponentError: bad component(expected host component): underscore_host.example
from /Users/gareth/.asdf/installs/ruby/3.1.3/lib/ruby/3.1.0/uri/generic.rb:591:in `check_host'
[3] pry(main)> URI("http://underscore_host.example")
=> #<URI::HTTP http://underscore_host.example>
```
`URI::Generic.new` allows a configurable `parser` positional argument to override the class' default parser, but other factory methods like `.build` don't allow this override.
Arguably this doesn't cause problems because at least in the case above, the URI can be built with the polymorphic constructor, but having the option to build URIs from explicit named parts is useful, and leaving the outdated functionality in the `Generic` class is ambiguous. It's possible that the whole Generic class and its subclasses aren't intended to be used directly how I'm intending here, but there's nothing I could see that suggested this is the case.
I'm not aware of the entire list of differences between RFC2396 and RFC3986. The relevant difference here is that in RFC2396 an individual segment of a host ([`domainlabel`s][4]) could only be `alphanum | alphanum *( alphanum | "-" ) alphanum`, whereas RFC3986 allows [hostnames][5] to include any of `ALPHA / DIGIT / "-" / "." / "_" / "~"`. It's possible that other differences might cause issues for developers, but since this has gone over 8 years without anyone else caring about this, this is definitely not especially urgent.
[1]: https://github.com/ruby/ruby/commit/bb83f32dc3e0424d25fa4e55d8ff32b061320e41
[2]: https://github.com/ruby/ruby/blob/28a17436503c3c4cb7a35b423a894b697cd80da9/…
[3]: https://github.com/ruby/ruby/blob/28a17436503c3c4cb7a35b423a894b697cd80da9/…
[4]: https://www.rfc-editor.org/rfc/rfc2396#section-3.2.2
[5]: https://www.rfc-editor.org/rfc/rfc3986#page-13
--
https://bugs.ruby-lang.org/
Issue #20050 has been reported by martinemde (Martin Emde).
----------------------------------------
Bug #20050: Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash)
https://bugs.ruby-lang.org/issues/20050
* Author: martinemde (Martin Emde)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin20]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Hi,
In the rubygems & bundler repositories we've now had two segfaults in the same exact code within days of merging a change to that code, both on ruby 3.2.2 on darwin20.
1. https://github.com/rubygems/rubygems/actions/runs/7110489973/job/1935706778…
2. https://github.com/rubygems/rubygems/actions/runs/7131889001/job/1942130416…
The specific error seems to happen when calculating the hash of the array in Gem::NameTuple#hash. The array contents that is being `.hash`ed both times should be exactly: `["has_metadata", "1.0", "ruby"]`. If I'm reading this correctly, this indicates that the crash is related either to creating this hash or storing this hash in the hash table (I'm not quite sure which is triggering the crash).
An excerpt of the C backtrace shows the same backtrace for both crashes:
```
-- C level backtrace information -------------------------------------------
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_vm_bugreport+0x7c4) [0x10cb0f994]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_bug_for_fatal_signal+0x1d0) [0x10c9158c0]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(sigsegv+0x5b) [0x10ca609ab]
/usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7ff810c14dfd]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_id_table_lookup+0x16) [0x10caa2a56]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(callable_method_entry_or_negative+0x5e) [0x10cae9c8e]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_check_funcall_basic_kw+0x129) [0x10caf0039]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(obj_any_hash+0x3c) [0x10c94bd2c]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(any_hash+0x52) [0x10c94bc12]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_st_add_direct+0x1d) [0x10ca69b7d]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(ar_try_convert_table+0x85) [0x10c94d015]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_hash_aset+0x18f) [0x10c94e26f]
```
I'm not sure how to follow this instruction in this case on GitHub actions: "Don't forget to include the Crash Report log file under DiagnosticReports directory in bug reports."
I have not been able to reproduce this locally with the same version of ruby (but I'm on darwin22 instead of 20). I will follow up if we continue to see this same crash.
--
https://bugs.ruby-lang.org/