January 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:120556] [Ruby master Bug#21018] Show invalid command line option more properly
by nobu (Nobuyoshi Nakada) 08 Jan '25

08 Jan '25

Issue #21018 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21018: Show invalid command line option more properly https://bugs.ruby-lang.org/issues/21018 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Currently the invalid command line option character is printed as-is. This makes the error message confusing sometimes. ```console $ ruby -$'\rx' (-h will show valid options) (RuntimeError) $ ruby -$'\U1f608' ruby: invalid option -? (-h will show valid options) (RuntimeError) ``` These are actually: ```console $ ruby -$'\rx' |& cat -e ruby: invalid option -^M (-h will show valid options) (RuntimeError)$ $ ruby -$'\U1f608' |& cat -e ruby: invalid option -M-p (-h will show valid options) (RuntimeError)$ ``` I think control characters and multibyte characters should be printed properly. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120529] [Ruby master Bug#21011] Constant massign segfaults in parse.y with shareable_constant_value: experimental_everything
by tompng (tomoya ishida) 08 Jan '25

08 Jan '25

Issue #21011 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21011: Constant massign segfaults in parse.y with shareable_constant_value: experimental_everything https://bugs.ruby-lang.org/issues/21011 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-06T01:50:53Z master c8e3d745fa) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- This code segfaults with parse.y ~~~ruby # shareable_constant_value: experimental_everything A,=1 ~~~ ~~~ $ ruby --parser=parse.y # shareable_constant_value: experimental_everything A,=1 -: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.5.0dev (2025-01-06T01:50:53Z master c8e3d745fa) [x86_64-linux] ~~~ -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120367] [Ruby master Bug#20978] Ractor[]/Thread[]/Fiber[] behavior difference
by zverok (Victor Shepelev) 07 Jan '25

07 Jan '25

Issue #20978 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #20978: Ractor[]/Thread[]/Fiber[] behavior difference https://bugs.ruby-lang.org/issues/20978 * Author: zverok (Victor Shepelev) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-22T06:08:19Z master 3808d29e20) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `Ractor.[]` and `.[]=` support string and symbol keys (treating them by string value, and also accepting anything responding to `#to_str`): ```ruby Ractor[:value] = 10 Ractor[:value] #=> 10 Ractor['value'] #=> 10 o = Object.new def o.to_str = 'value' Ractor[o] #=> 10 Ractor[1] # in 'Ractor.[]': 1 is not a symbol nor a string (TypeError) ``` But `Fiber.[]` only accept symbols: ```ruby Fiber[:value] = 10 Fiber['value'] # in 'Fiber.[]': wrong argument type String (expected Symbol) (TypeError) ``` `Thread#[]` and `#[]=` behave like Ractor’s. (The documentation for Fiber and Thread follows the reality—while Ractor’s current docs don’t specify key type at all—but the discrepancy feels somewhat weird.) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:119801] [Ruby master Feature#20878] A new C API to create a String by adopting a pointer: `rb_enc_str_adopt(const char *ptr, long len, long capa, rb_encoding *enc)`
by byroot (Jean Boussier) 07 Jan '25

07 Jan '25

Issue #20878 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20878: A new C API to create a String by adopting a pointer: `rb_enc_str_adopt(const char *ptr, long len, long capa, rb_encoding *enc)` https://bugs.ruby-lang.org/issues/20878 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context A common use case when writing C extensions is to generate text or bytes into a buffer, and to return it back wrapped into a Ruby String. Examples are `JSON.generate(obj) -> String`, and all other format serializers, compression libraries such as `ZLib.deflate`, etc, but also methods such as `Time.strftime`, ### Current Solution #### Work in a buffer and copy the result The most often used solution is to work with a native buffer and to manage a native allocated buffer, and once the generation is done, call `rb_str_new*` to copy the result inside memory managed by Ruby. It works, but isn't very efficient because it cause an extra copy and an extra `free()`. On `ruby/json` macro-benchmarks, this represent around 5% of the time spent in `JSON.generate`. ```c static void fbuffer_free(FBuffer *fb) { if (fb->ptr && fb->type == FBUFFER_HEAP_ALLOCATED) { ruby_xfree(fb->ptr); } } static VALUE fbuffer_to_s(FBuffer *fb) { VALUE result = rb_utf8_str_new(FBUFFER_PTR(fb), FBUFFER_LEN(fb)); fbuffer_free(fb); return result; } ``` #### Work inside RString allocated memory Another way this is currently done, is to allocate an `RString` using `rb_str_buf_new`, and write into it with various functions such as `rb_str_catf`, or writing past `RString.len` through `RSTRING_PTR` and then resize it with `rb_str_set_len`. The downside with this approach is that it contains a lot of inefficiencies, as `rb_str_set_len` will perform numerous safety checks, compute coderange, and write the string terminator on every invocation. Another major inneficiency is that this API make it hard to be in control of the buffer growth, so it can result in a lot more `realloc()` calls than manually managing the buffer. This method is used by `Kernel#sprintf`, `Time#strftime` etc, and when I attempted to improve `Time#strftime` performance, this problem showed up as the biggest bottleneck: - https://github.com/ruby/ruby/pull/11547 - https://github.com/ruby/ruby/pull/11544 - https://github.com/ruby/ruby/pull/11542 ### Proposed API I think a more effcient way to do this would be to work with a native buffer, and then build a RString that "adopt" the memory region. Technically, you can currently do this by reaching directly into `RString` members, but I don't think it's clean, and a dedicated API would be preferable: ```c /** * Similar to rb_str_new(), but it adopts the pointer instead of copying. * * @param[in] ptr A memory region of `capa` bytes length. MUST have been allocated with `ruby_xmalloc` * @param[in] len Length of the string, in bytes, not including the * terminating NUL character, not including extra capacity. * @param[in] capa The usable length of `ptr`, in bytes, including the * terminating NUL character. * @param[in] enc Encoding of `ptr`. * @exception rb_eArgError `len` is negative. * @return An instance of ::rb_cString, of `len` bytes length, `capa - 1` bytes capacity, * and of `enc` encoding. * @pre At least `capa` bytes of continuous memory region shall be * accessible via `ptr`. * @pre `ptr` MUST have been allocated with `ruby_xmalloc`. * @pre `ptr` MUST not be manually freed after `rb_enc_str_adopt` has been called. * @note `enc` can be a null pointer. It can also be seen as a routine * identical to rb_usascii_str_new() then. */ rb_enc_str_adopt(const char *ptr, long len, long capa, rb_encoding *enc); ``` An alternative to the `adopt` term, could be `move`. -- https://bugs.ruby-lang.org/

8 31

[ruby-core:120281] [Ruby master Feature#20960] Support building OpenSSL for Ruby with AWS-LC
by sachiang (Samuel Chiang) 07 Jan '25

07 Jan '25

Issue #20960 has been reported by sachiang (Samuel Chiang). ---------------------------------------- Feature #20960: Support building OpenSSL for Ruby with AWS-LC https://bugs.ruby-lang.org/issues/20960 * Author: sachiang (Samuel Chiang) * Status: Open ---------------------------------------- Hello, I’m an engineer at AWS working on [AWS-LC](https://github.com/aws/aws-lc), AWS’s open-source cryptographic library maintained for AWS and their customers. AWS-LC supports CPU-specific performance optimizations for AWS Graviton 2, [AWS Graviton 3](https://github.com/aws/aws-lc/commit/ae87faf735c0241a115542b1c1022d12556…, and [Intel x86-64 with AVX-512 instructions](https://github.com/aws/aws-lc/commit/e22cf5065761bec8882c66ce…. We’ve formally verified [a subset of](https://github.com/awslabs/aws-lc-verification#verified-code) AWS-LC’s cryptographic primitives, and continue to invest in expanding this coverage. AWS-LC can be also built in FIPS mode to help consumers meet FIPS 140-3 compliance requirements. To give Ruby users a well-documented and supported way to take advantage of these investments, we would like to upstream build compatibility for AWS-LC into Ruby. We believe that this would provide the best experience for users wishing to build Ruby against AWS-LC. It would also allow users to circumvent maintaining and applying their own patch sets to build Ruby with AWS-LC. Earlier this year, we[engaged with the CPython maintainers](https://discuss.python.org/t/support-building-ssl-and-hashlib-… to successfully address similar needs for our respective users. We are working on patch sets to integrate Ruby‘s OpenSSL module with AWS-LC. AWS-LC is committed to backwards compatibility and we aim to keep our API stable. Our open source repository has CI jobs ([here](https://github.com/aws/aws-lc/tree/main/tests/ci/integration) and [here](https://github.com/aws/aws-lc/blob/main/.github/workflows/integration…) asserting every change’s compatibility with multiple different open-source projects. We’ve [recently added Ruby 3.1 and 3.2](https://github.com/aws/aws-lc/commit/57133c00c71f9a6790c7c9d9a63ab883a… to this test suite and we’re in the midst of incorporating Ruby’s main branch and 3.3. These tests are used to catch compatibility regressions against every change before they’re merged and to resolve potential build issues beforehand when upstream projects make relevant changes. Relevant unit tests from the upstream projects’ are also ran to confirm that the underlying `libcrypto` & `libssl` behave as expected. By expanding our regular testing processes to include Ruby, we proactively prevent any unanticipated breaks in the Ruby/AWS-LC build. The proposed integration supports all features of Ruby’s OpenSSL module, except for the use of DHE cipher suites in `libssl`. Excluding this, we have confirmed that all relevant unit tests for Ruby’s OpenSSL module perform as expected. If you folks agree that this integration would be beneficial for Ruby and its consumers, I’d be more than happy to put together a PR. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120506] [Ruby master Bug#21006] `defined?((receiver).method)` raises Stack consistency error
by tompng (tomoya ishida) 06 Jan '25

06 Jan '25

Issue #21006 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21006: `defined?((receiver).method)` raises Stack consistency error https://bugs.ruby-lang.org/issues/21006 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ $ ruby -ve "defined?((foo).bar)" ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +MN +PRISM [arm64-darwin22] -e:1: warning: possibly useless use of defined? in void context -e:1: [BUG] Stack consistency error (sp: 7, bp: 6) ~~~ -- https://bugs.ruby-lang.org/

1 1

[ruby-core:120467] [Ruby master Feature#20999] Add RubyVM object source support
by bkuhlmann (Brooke Kuhlmann) 05 Jan '25

05 Jan '25

Issue #20999 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Feature #20999: Add RubyVM object source support https://bugs.ruby-lang.org/issues/20999 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open ---------------------------------------- Hello. 👋 I'd like to propose adding the ability to acquire the source of any object within memory via the RubyVM. A couple use cases come to mind: - This would simplify the [Method Source](https://github.com/banister/method_source) gem implementation and possibly eliminate the need for the gem. - Another use case is this allows DSLs, like [Initable](https://alchemists.io/projects/initable), to elegantly acquire the source code of objects and/or functions (in my case, I'm most interested in the lazy evaluation of function bodies). ⚠️ I'm also aware that the [RubyVM](https://docs.ruby-lang.org/en/master/RubyVM.html) documentation clearly stats this isn't meant for production use: > This module is for very limited purposes, such as debugging, prototyping, and research. Normal users must not use it. This module is not portable between Ruby implementations. ...but I'd like to entertain this proposed feature request, regardless. Here's an example, using the aforementioned [Initable](https://alchemists.io/projects/initable) gem, where I use the RubyVM to obtain the source of a `Proc`: ``` ruby class Demo include Initable[%i[req name], [:key, :default, proc { Object.new }]] end puts Demo.new("demo").inspect #<Demo:0x000000014349a400 @name="demo", @default=#<Object:0x000000014349a360>> ``` With the above, I'm lazily obtaining the source code of the `Proc` in order to dynamically define the `#initialize` method (essentially a `module_eval` on `Demo`, simply speaking) using a nested array as specified by [Method#parameters](https://docs.ruby-lang.org/en/master/Method.html#method-… because I don't want an instance of `Object` until initialization is necessary. ## Context Prior to the release of Ruby 3.4.0, you could do this: ``` ruby function = proc { Object.new } ast = RubyVM::AbstractSyntaxTree.of function ast.children.last.source # "Object.new" ``` Unfortunately, with the release of Ruby 3.4.0 -- which defaults to the [Prism](https://ruby.github.io/prism/rb/index.html) parser -- the ability to acquire source code is a bit more complicated. For example, to achieve what is shown above, you have to do this: ``` ruby function = proc { Object.new } RubyVM::InstructionSequence.of(function).script_lines # [ # "function = proc { Object.new }\n", # "RubyVM::InstructionSequence.of(function).script_lines\n", # "\n", # "" # ] ``` Definitely doable, but now requires more work to pluck `"Object.new"` from the body of the `Proc`. One solution is to use a regular expression to find and extract the first line of the result. Example: ``` ruby / proc # Proc statement. \s* # Optional space. \{ # Block open. (?<body>.*?) # Source code body. \} # Block close. /x ``` Definitely doesn't account for all use cases (like when a `Proc` spans multiple lines or uses `do...end` syntax) but will get you close. ## How I think there are a couple of paths that might be nice to support this use case. ### Option A Teach `RubyVM::InstructionSequence` to respond to `#source` which would be similar to what was possible prior to Ruby 3.4.0. Example: ``` ruby function = proc { Object.new } RubyVM::InstructionSequence.of(function).source # "Object.new" ``` ### Option B This is something that Samuel Williams [mentioned](https://bugs.ruby-lang.org/issues/6012#note-13) in [Feature 6012](https://bugs.ruby-lang.org/issues/6012) which would be to provide a `Source` object as answered by `Method#source` and `Proc#source`. Example (using a `Proc`): ``` ruby # Implementation # Method#source (i.e. Source.new path, line_number, line_count, body) # Usage: function = proc { Object.new } method.source.code # "Object.new" method.source.path # "$HOME/demo.rb" method.source.location # [2, 0, 3, 3] ``` ### Option C It could be nice to support both Option A and B. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:120489] [Ruby master Feature#6012] Proc#source_location also return the column
by bkuhlmann (Brooke Kuhlmann) 05 Jan '25

05 Jan '25

Issue #6012 has been updated by bkuhlmann (Brooke Kuhlmann). 💡 Please see [Feature 21005](https://bugs.ruby-lang.org/issues/21005) as an evolution of this discussion based on feedback I've had with Kevin Newton and Benoit Daloze. Thanks. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-111272 * Author: rogerdpack (Roger Pack) * Status: Assigned * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120485] [Ruby master Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 05 Jan '25

05 Jan '25

Issue #6012 has been updated by Eregon (Benoit Daloze). One idea for this new SourceLocation/CodeLocation class would be under the new `Ruby` module, see https://bugs.ruby-lang.org/issues/20884#note-3 ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-111269 * Author: rogerdpack (Roger Pack) * Status: Assigned * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117929] [Ruby master Feature#20498] Negated method calls
by MaxLap (Maxime Lapointe) 05 Jan '25

05 Jan '25

Issue #20498 has been reported by MaxLap (Maxime Lapointe). ---------------------------------------- Feature #20498: Negated method calls https://bugs.ruby-lang.org/issues/20498 * Author: MaxLap (Maxime Lapointe) * Status: Open ---------------------------------------- I want to propose the following syntax: `foo.!bar`. I know it's already valid syntax, but please read on for details. When someone write a somewhat long line of code that is negated, the main way I've seen of doing it is: ``` must_create_user = !User.where(somelong: :condition, even_more: "thing").exists? ``` I personally highly dislike it, as I must keep the "not" in the back of my mind as I read the line. When quickly reading a line like this, it's super easy to misread and understand the opposite result. The current ways around this I can think of are: * rename the variable (can be annoying) * Use `unless` (only possible when in a condition; some people, like me, have a hard time grapsping a `unless`) * use a `.!`in the end (`foo.exists?.!`), I've never seen that and it looks ugly to me (this is subjective). * create a new method name with the negated meaning (not always possible) My proposal would look like this: ``` must_create_user = User.where(somelong: :condition, even_more: "thing").!exists? ``` You cannot forget the bang that you saw 15 words ago, it's right there. It also basically reads as English: "user where ... doesn't exists". The main argument against this I can think of is that it's technically already a valid syntax. I believe it's frowned upon to override the bang operator and I'm not aware of places where it is overridden to with also having a parameter. I made a prototype in RubyNext, which you can try here: https://ruby-next.github.io/#gist:0e133bf6f27f2437193dc034d58083dc -- https://bugs.ruby-lang.org/

8 9