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

[ruby-core:119442] [Ruby master Feature#20782] Introduction of Happy Eyeballs Version 2 (RFC8305) in TCPSocket.new
by shioimm (Misaki Shioi) 09 Dec '24

09 Dec '24

Issue #20782 has been reported by shioimm (Misaki Shioi). ---------------------------------------- Feature #20782: Introduction of Happy Eyeballs Version 2 (RFC8305) in TCPSocket.new https://bugs.ruby-lang.org/issues/20782 * Author: shioimm (Misaki Shioi) * Status: Open ---------------------------------------- This is an implementation of Happy Eyeballs version 2 (RFC 8305) in `TCPSocket.new`. See https://github.com/ruby/ruby/pull/11653 ### Background Prior to this implementation, I implemented Happy Eyeballs Version 2 (HEv2) for `Socket.tcp` in https://github.com/ruby/ruby/pull/9374. HEv2 is an algorithm defined in [RFC 8305](https://datatracker.ietf.org/doc/html/rfc8305), aimed at improving network connectivity. For more details on the specific cases that HEv2 helps, please refer to https://bugs.ruby-lang.org/issues/20108. ### Proposal & Outcome This proposal implements the same HEv2 algorithm in `TCPSocket.new`. Since `TCPSocket.new` is used more widely than `Socket.tcp`, this change is expected to broaden the impact of HEv2's benefits. Like `Socket.tcp`, I have also added `fast_fallback` keyword argument to `TCPSocket.new`. This option is set to true by default, enabling the HEv2 functionality. However, users can explicitly set it to false to disable HEv2 and use the previous behavior of `TCPSocket.new`. It should be noted that HEv2 is enabled only in environments where pthreads are available. This specification follows the approach taken in https://bugs.ruby-lang.org/issues/19965, where name resolution can be interrupted. (In environments where pthreads are not available, the `fast_fallback` option is ignored.) ### Performance Below is the benchmark of 100 requests to `www.ruby-lang.org` with the fast_fallback option set to true and false, respectively. While there is a slight performance degradation when HEv2 is enabled, the degradation is smaller compared to that seen in `Socket.tcp` . ```ruby require 'socket' require 'benchmark' hostname = "www.ruby-lang.org" port = 80 n = 100 Benchmark.bmbm do |x| x.report("fast_fallback: true") do n.times { TCPSocket.new(hostname, port).close } end x.report("fast_fallback: false") do n.times { TCPSocket.new(hostname, port, fast_fallback: false).close } end end ``` ``` ~/s/build ❯❯❯ ../install/bin/ruby ../ruby/test.rb Rehearsal -------------------------------------------------------- fast_fallback: true 0.017588 0.097045 0.114633 ( 1.460664) fast_fallback: false 0.014033 0.078984 0.093017 ( 1.413951) ----------------------------------------------- total: 0.207650sec user system total real fast_fallback: true 0.020891 0.124054 0.144945 ( 1.473816) fast_fallback: false 0.018392 0.110852 0.129244 ( 1.466014) ``` -- https://bugs.ruby-lang.org/

6 11

[ruby-core:119806] [Ruby master Misc#20879] DevMeeting-2024-12-12
by mame (Yusuke Endoh) 09 Dec '24

09 Dec '24

Issue #20879 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #20879: DevMeeting-2024-12-12 https://bugs.ruby-lang.org/issues/20879 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2024/12/12 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2024/12/09. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

7 6

[ruby-core:120132] [Ruby master Misc#16124] Let the transient heap belong to objspace
by ko1 (Koichi Sasada) 07 Dec '24

07 Dec '24

Issue #16124 has been updated by ko1 (Koichi Sasada). Status changed from Assigned to Rejected transient heap was removed. ---------------------------------------- Misc #16124: Let the transient heap belong to objspace https://bugs.ruby-lang.org/issues/16124#change-110882 * Author: methodmissing (Lourens Naudé) * Status: Rejected * Assignee: ko1 (Koichi Sasada) ---------------------------------------- As per comment from Nobu in https://github.com/ruby/ruby/pull/2303#issuecomment-523248875 , I took an initial stab @ a tighter integration between objspace and the transient heap in https://github.com/ruby/ruby/pull/2400 ### Benefits * Multi-VM (MVM) friendly - ( vm -> objspace -> theap ) * The 32MB (current size) arena lazy allocated on ruby init is now properly freed on shutdown as well * It feels strange that the evacuation from the current global theap is to objspace, whereas the space evacuated from is a global arena. ### Not so great * A fast reference to a global variable `global_transient_heap` becomes a function call to `rb_objspace_get_theap()` and related pointer chasing from vm -> objspace -> theap * Some internal transient heap structs moved to the header file now leaks into all other reference sites where this source file (`transient_heap.c`) as previously just used for API * I'm not sure exactly of the boundary Koichi had in mind for the GC compile module and how tightly it should (or shouldn't) be coupled to the transient heap. `struct rb_objspace*` declarations elsewhere for example reveals nothing about the structure members for example, whereas with this PR a lot of transient heap internals are exposed via the header file now * Also possible to move `transient_heap.c` into `gc.c` - I feel theap is not an experimental feature anymore and has been stable for quite some time with plausible performance benefits. The downside of that is `gc.c` is quite dense already, but then all ruby heap management concerns belong to one compile unit. In a similar vein the global method cache could perhaps belong to the VM instance as well, effectively better alignment with MVM and also easier to have a balanced VM setup and teardown sequence without anything left dangling on ruby shutdown. Thoughts? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120120] [Ruby master Bug#20933] Unexpected IO::Buffer::MaskError in IO::Buffer#xor!
by agitter (Alexander Gitter) 07 Dec '24

07 Dec '24

Issue #20933 has been reported by agitter (Alexander Gitter). ---------------------------------------- Bug #20933: Unexpected IO::Buffer::MaskError in IO::Buffer#xor! https://bugs.ruby-lang.org/issues/20933 * Author: agitter (Alexander Gitter) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-06T12:47:35Z master 78614ee900) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The following script raises `Mask overlaps source buffer! (IO::Buffer::MaskError)` most of the time when running it on my Ubuntu 24.04 machine. "Most of the time" means this sometimes (20% - 30%) works without issue. ```ruby a = IO::Buffer.new(1024 * 1024) b = IO::Buffer.new(1024 * 1024) a = IO::Buffer.new(1024 * 1024) # Removing this line makes this work much more reliably a.xor!(b) ``` I'm guessing this is somehow related to these being `MAPPED` buffers - reducing the sizes to 1024 bytes also fixes the problem. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120126] [Ruby master Feature#18930] Officially deprecate class variables
by Dan0042 (Daniel DeLorme) 06 Dec '24

06 Dec '24

Issue #18930 has been updated by Dan0042 (Daniel DeLorme). I'm still against deprecating, either soft or hard, but I believe the errors could be improved. ```ruby class A def self.foo p @@foo ||= rand end end class B < A p @@foo = 2 end B.foo ``` In this code, the @@foo variable is overtaken but the "overtaken" error isn't triggered because even though the `foo` method is invoked on B, it was defined in A. If this could be improved to raise an error, I believe it might relieve some of the confusion over class variables. ---------------------------------------- Feature #18930: Officially deprecate class variables https://bugs.ruby-lang.org/issues/18930#change-110877 * Author: Eregon (Benoit Daloze) * Status: Rejected ---------------------------------------- Ruby's class variables are very confusing, and it seem many people agree they should be avoided (#18927). How about we deprecate them officially? Concretely: * Mention in the documentation that class variables are deprecated and should be avoided/should not be used. * Add a parse-time deprecation warning, now that we only see those with `Warning[:deprecation] = true` it seems reasonable to add. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120124] [Ruby master Feature#18930] Officially deprecate class variables
by shan (Shannon Skipper) 06 Dec '24

06 Dec '24

Issue #18930 has been updated by shan (Shannon Skipper). Can we formally document they are soft deprecated or at least not recommended for use. In the Ruby community we often see new folk struggle greatly with them and have to recommend against their use over and over. ---------------------------------------- Feature #18930: Officially deprecate class variables https://bugs.ruby-lang.org/issues/18930#change-110875 * Author: Eregon (Benoit Daloze) * Status: Rejected ---------------------------------------- Ruby's class variables are very confusing, and it seem many people agree they should be avoided (#18927). How about we deprecate them officially? Concretely: * Mention in the documentation that class variables are deprecated and should be avoided/should not be used. * Add a parse-time deprecation warning, now that we only see those with `Warning[:deprecation] = true` it seems reasonable to add. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118923] [Ruby master Bug#20690] URI.encode_www_form_component method escapes tilde when it's not supposed to
by y4m4p (Masahiro Yamashita) 06 Dec '24

06 Dec '24

Issue #20690 has been reported by y4m4p (Masahiro Yamashita). ---------------------------------------- Bug #20690: URI.encode_www_form_component method escapes tilde when it's not supposed to https://bugs.ruby-lang.org/issues/20690 * Author: y4m4p (Masahiro Yamashita) * Status: Open * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin21] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ## Problem As the title says, `Uri.encode_www_form_component` is escaping tilde (`~`) where it should not according to the RFC3986. Ref: https://datatracker.ietf.org/doc/html/rfc3986#section-2.3 There was a previous issue with the same problem, https://bugs.ruby-lang.org/issues/6696 which has been resolved and merged. --- Since `URI.escape` is now obsolete and gone, the preferred way to escape URI characters are to choose from the following methods. - `URI.encode_www_form_component` (or, `URI.encode_www_form` which uses this) - `CGI.escape` - `ERB::Util.#url_encode` - `WEBrick::HTTPUtils.#escape_form` - `WEBrick::HTTPUtils.#escape` This issue does not occur when using any of the methods except `URI.encode_www_form_component`. These preferred options are not compatible with each other, making it a poor experience for Ruby users. ### Minimum replication ``` ruby # URI irb(main):002:0> require 'uri' => true irb(main):004:0> URI.encode_www_form_component("ruby~test") => "ruby%7Etest" # CGI irb(main):001:0> require 'cgi' => true irb(main):003:0> CGI.escape("ruby~test") => "ruby~test" # ERB irb(main):009:0> require 'erb' => true irb(main):012:0> ERB::Util.url_encode("ruby~test") => "ruby~test" # Webrick # needs webrick gem installed [3] pry(main)> require 'webrick' => true [4] pry(main)> WEBrick::HTTPUtils.escape_form("ruby~test") => "ruby~test" [5] pry(main)> WEBrick::HTTPUtils.escape("ruby~test") => "ruby~test" ``` ## Real world use-case problem I have a use-case problem with using URI when implementing a OIDC with PKCE client / server setup. When trying to generate a GET URI for Open ID Connect with PKCE, you need to provide a `code_verifier` value to the Authorization server, which actually requires you to use the tilde without escaping. Ref: https://www.oauth.com/oauth2-servers/pkce/authorization-request/ > When the native app begins the authorization request, instead of immediately launching a browser, the client first creates what is known as a “code verifier“. This is a cryptographically random string using the characters A-Z, a-z, 0-9, and the punctuation characters -._~ (hyphen, period, underscore, and tilde), between 43 and 128 characters long. The inconsistent encoding is problematic for the Server and Client both, since both ends needs to have an agreement on using tilde as an escaped character or an unescaped character. Logically speaking, `~` should be sent AS-IS and not to be escaped, since the `code_challenge` value and `code_verifier` values are strictly checked using a Hash generation function `Digest::SHA256.digest`, which generates a different Hash value depending on `~`(non escaped) or `%7E`(escaped). These parameters from user inputs are usually not meant to be tampered with for security sake, so it's best to have tilde `~` to be unescaped from the beginning. ## Related issues - https://bugs.ruby-lang.org/issues/6696 - This seems to have been resolved and merged. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120087] [Ruby master Bug#20928] Current 3.4-dev cannot be built with jemalloc activated in macOS
by hachi8833 (Shozo Hatta) 05 Dec '24

05 Dec '24

Issue #20928 has been reported by hachi8833 (Shozo Hatta). ---------------------------------------- Bug #20928: Current 3.4-dev cannot be built with jemalloc activated in macOS https://bugs.ruby-lang.org/issues/20928 * Author: hachi8833 (Shozo Hatta) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Today I found that the current 3.4-dev is unable to build with jemalloc activated, while 3.3.4 or any lower versions can be build as usual with or w/o jemalloc activated. * macOS Sequoia: 15.1.1 (M3 Chip) * env (FYI: `--with-opt-dir=$(brew --prefix jemalloc)"` does not affect the result): ``` shell export RUBY_CONFIGURE_OPTS="--disable-install-doc --disable-shared --with-jemalloc --with-opt-dir=$(brew --prefix jemalloc)" export LD_PRELOAD=`jemalloc-config --libdir`/libjemalloc.dylib ``` * setup: ``` shell $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables package-id: com.apple.pkg.CLTools_Executables version: 16.1.0.0.1.1729049160 volume: / location: / $ brew --config HOMEBREW_VERSION: 4.4.9 ORIGIN: https://github.com/Homebrew/brew HEAD: 2e780004c92f16a96036d3d43569c2924c4e54f5 Last commit: 12 hours ago Branch: stable Core tap HEAD: 77f65298ec57b87241038503aabc6dfd1ead0497 Core tap last commit: 9 weeks ago Core tap JSON: 03 Dec 08:13 UTC Core cask tap JSON: 03 Dec 08:05 UTC HOMEBREW_PREFIX: /opt/homebrew HOMEBREW_CASK_OPTS: [] HOMEBREW_MAKE_JOBS: 8 HOMEBREW_NO_ENV_HINTS: set HOMEBREW_SORBET_RUNTIME: set Homebrew Ruby: 3.3.6 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.3.6/bin/ruby CPU: octa-core 64-bit arm_ibiza Clang: 16.0.0 build 1600 Git: 2.47.1 => /opt/homebrew/bin/git Curl: 8.7.1 => /usr/bin/curl macOS: 15.1.1-arm64 CLT: 16.1.0.0.1.1729049160 Xcode: N/A Rosetta 2: false ``` * build with 3.4-dev: ``` shell $ rbenv install 3.4-dev rbenv: /Users/hachi8833/.anyenv/envs/rbenv/versions/3.4-dev already exists continue with installation? (y/N) y ruby-build: using openssl@3 from homebrew ==> Cloning https://github.com/ruby/ruby.git... -> git clone --depth 1 --branch master https://github.com/ruby/ruby.git ruby-master Cloning into 'ruby-master'... remote: Enumerating objects: 12679, done. remote: Counting objects: 100% (12679/12679), done. remote: Compressing objects: 100% (10177/10177), done. remote: Total 12679 (delta 1499), reused 6014 (delta 1223), pack-reused 0 (from 0) Receiving objects: 100% (12679/12679), 16.82 MiB | 7.65 MiB/s, done. Resolving deltas: 100% (1499/1499), done. Updating files: 100% (11561/11561), done. ==> Installing ruby-master... -> autoreconf -i ruby-build: using readline from homebrew ruby-build: using libyaml from homebrew ruby-build: using gmp from homebrew -> ./configure "--prefix=$HOME/.anyenv/envs/rbenv/versions/3.4-dev" --with-openssl-dir=/opt/homebrew/opt/openssl@3 --with-readline-dir=/opt/homebrew/opt/readline --with-libyaml-dir=/opt/homebrew/opt/libyaml --with-gmp-dir=/opt/homebrew/opt/gmp --disable-install-doc --disable-shared --with-jemalloc --with-opt-dir=/opt/homebrew/opt/jemalloc -> make -j 8 BUILD FAILED (macOS 15.1.1 on arm64 using ruby-build 20241105-4-g87c272cd) ``` * detailed-log: ``` shell ... compiling gc.c gc.c:51:11: fatal error: 'malloc.h' file not found 51 | # include <malloc.h> | ^~~~~~~~~~ compiling hash.c compiling inits.c compiling io.c compiling marshal.c 1 error generated. make: *** [gc.o] Error 1 make: *** Waiting for unfinished jobs.... touch yjit/target/release/libyjit.a external command failed with status 2 ... ``` As far as I checked gc.c, at least `HAVE_MALLOC_USABLE_SIZE` and `HAVE_MALLOC_TRIM` directives are missing in 3.4-dev (see the attached). I hope these information would help resolve the issue 🙏 Thank you in advance, ---Files-------------------------------- 20241203_180021_r2uuD9.png (1.87 MB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120080] [Ruby master Bug#20926] shareable_constant_value: experimental_everything crashes with parse.y
by tenderlovemaking (Aaron Patterson) 05 Dec '24

05 Dec '24

Issue #20926 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #20926: shareable_constant_value: experimental_everything crashes with parse.y https://bugs.ruby-lang.org/issues/20926 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This program crashes with parse.y as the parser: ``` ./miniruby --dump=insns --parser=parse.y -v -e'# shareable_constant_value: experimental_everything C = { **{ } }' ``` Backtrace from LLDB looks like this: ``` (lldb) run Process 66489 launched: '/Users/aaron/git/ruby/miniruby' (arm64) Process 66489 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3523922faa9c0058) frame #0: 0x0000000100220f84 miniruby`RB_BUILTIN_TYPE(obj=3829064841618522200) at value_type.h:191:30 188 * RB_SPECIAL_CONST_P check. */ 189 __asm volatile("": : :"memory"); 190 #endif -> 191 VALUE ret = RBASIC(obj)->flags & RUBY_T_MASK; 192 return RBIMPL_CAST((enum ruby_value_type)ret); 193 } 194 Target 0: (miniruby) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3523922faa9c0058) * frame #0: 0x0000000100220f84 miniruby`RB_BUILTIN_TYPE(obj=3829064841618522200) at value_type.h:191:30 frame #1: 0x0000000100220e84 miniruby`RCLASS_SINGLETON_P [inlined] rbimpl_RB_TYPE_P_fastpath(obj=3829064841618522200, t=RUBY_T_CLASS) at value_type.h:352:19 frame #2: 0x0000000100220d0c miniruby`RCLASS_SINGLETON_P(klass=3829064841618522200) at class.h:202:12 frame #3: 0x0000000100220c80 miniruby`rb_class_real(cl=3829064841618522200) at object.c:290:10 frame #4: 0x0000000100220fd8 miniruby`rb_obj_class(obj=6171908688) at object.c:299:12 frame #5: 0x0000000100172218 miniruby`rb_hash_aset(hash=4367092992, key=6171908688, val=4367092800) at hash.c:2931:10 frame #6: 0x0000000100090a1c miniruby`compile_shareable_literal_constant(iseq=0x00000001043e10d0, ret=0x000000016fdfdad8, shareable=rb_parser_shareable_everything, dest=0x000000014c7c5468, node=0x000000014c7c5548, level=0, value_p=0x000000016fdfdac8, shareable_literal_p=0x000000016fdfdad4) at compile.c:10507:21 frame #7: 0x000000010007db5c miniruby`compile_shareable_constant_value(iseq=0x00000001043e10d0, ret=0x000000016fdfe518, shareable=rb_parser_shareable_everything, lhs=0x000000014c7c5468, value=0x000000014c7c5548) at compile.c:10591:9 frame #8: 0x0000000100073e10 miniruby`iseq_compile_each0(iseq=0x00000001043e10d0, ret=0x000000016fdfe518, node=0x000000014c7c5468, popped=0) at compile.c:10786:13 frame #9: 0x0000000100057354 miniruby`iseq_compile_each(iseq=0x00000001043e10d0, ret=0x000000016fdfe518, node=0x000000014c7c5468, popped=0) at compile.c:10624:12 frame #10: 0x0000000100056f0c miniruby`rb_iseq_compile_node(iseq=0x00000001043e10d0, node=0x000000014c7c5578) at compile.c:919:13 frame #11: 0x00000001001b8cbc miniruby`rb_iseq_new_with_opt(ast_value=4366143936, name=4343347824, path=4343499984, realpath=4366954464, first_lineno=0, parent=0x0000000102e23a40, isolated_depth=0, type=ISEQ_TYPE_MAIN, option=0x000000016fdfe648, script_lines=4) at iseq.c:1011:5 frame #12: 0x00000001001b9230 miniruby`rb_iseq_new_main(ast_value=4366143936, path=4343499984, realpath=4366954464, parent=0x0000000102e23a40, opt=1) at iseq.c:915:12 frame #13: 0x000000010031715c miniruby`process_options(argc=0, argv=0x000000016fdff5d8, opt=0x000000016fdff0e0) at ruby.c:2627:20 frame #14: 0x0000000100316000 miniruby`ruby_process_options(argc=3, argv=0x000000016fdff5c0) at ruby.c:3169:12 frame #15: 0x00000001001260a8 miniruby`ruby_options(argc=3, argv=0x000000016fdff5c0) at eval.c:117:16 frame #16: 0x0000000100001940 miniruby`rb_main(argc=3, argv=0x000000016fdff5c0) at main.c:43:26 frame #17: 0x00000001000018cc miniruby`main(argc=3, argv=0x000000016fdff5c0) at main.c:68:12 frame #18: 0x0000000199240274 dyld`start + 2840 ``` I think the program is supposed to emit instructions that look like this: ``` $ ruby -v --dump=insns test.rb ruby 3.3.4 (2024-07-16 revision 425e468d25) [arm64-darwin23] == disasm: #<ISeq:<main>@test.rb:1 (1,0)-(3,13)> 0000 putobject {nil=>{}} ( 3)[Li] 0002 dup 0003 putspecialobject 3 0005 setconstant :C 0007 leave ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120106] [Ruby master Bug#20931] Using `in` as an expression requires extra parentheses
by stephenprater (Stephen Prater) 04 Dec '24

04 Dec '24

Issue #20931 has been reported by stephenprater (Stephen Prater). ---------------------------------------- Bug #20931: Using `in` as an expression requires extra parentheses https://bugs.ruby-lang.org/issues/20931 * Author: stephenprater (Stephen Prater) * Status: Open * ruby -v: 3.3.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- TBH - I'm not sure if this is a bug or not - but it certainly surprising behavior and I'd at least like to understand it. Given a hash t - that can be pattern matched: `t = {a: 1, b:1 }` ``` ruby r = t in {a: 1, c:1 } # returns `false` r # {a: 1, c: 1} wat ``` Presumably this is because `=` binds higher than `in` - so that expression is equivalent to `(r = t) in {a: 1, c: 1}` But in that case - why does using the results of `in` require an additional set of parentheses to avoid a syntax error when the result of the expression is used as an argument to a method? ``` ruby puts(t in {a: 1, c: 1}) # syntax error puts((t in {a: 1, c: 1}) # false ``` Especially since this works fine: ``` ruby puts(case t; in { a: 1, c:1 }; true; else false; end) ``` -- https://bugs.ruby-lang.org/

3 3