March 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:112866] [Ruby master Feature#19528] `JSON.load` defaults are surprising (`create_additions: true`)

by byroot (Jean Boussier)

Issue #19528 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #19528: `JSON.load` defaults are surprising (`create_additions: true`) https://bugs.ruby-lang.org/issues/19528 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- I'm not sure if it was actually intended, but there's some tacit naming convention for serializers in Ruby to use `load` and `dump` as methods, likely inspired from `Marshal` and `YAML`. Because of this it's extremely common to see code that uses `JSON.load` expecting a simple, no surprise, and safe JSON parsing. However that's `JSON.parse`. `JSON.load` has this very surprising behavior (albeit perfectly documented), of de-serializing more complex types: ```ruby >> JSON.load('{ "json_class": "String", "raw": [72, 101, 108, 108, 111] }') => "Hello" ``` It's particularly weird because aside from the `String` extension that is eagerly defined, for other types you have to `require "json/add/core"`. Seasoned Ruby developers know about this of course, and [it is banned by various linters](https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Security/JSONLoad), but it keeps popping regularly in gems security releases and such. ### Proposal Assuming entirely removing this feature is not an option, I think `json 2.x` should warn when this feature is actually being used, and `json 3.x` should disable it by default and require users to explicitly use `JSON.load(str, create_additions: true)` to keep the old behavior. -- https://bugs.ruby-lang.org/

1 year, 1 month

4
4
0 0

[ruby-core:113028] [Ruby master Bug#19551] Backport commits for CI failures

by hsbt (Hiroshi SHIBATA)

Issue #19551 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19551: Backport commits for CI failures https://bugs.ruby-lang.org/issues/19551 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Priority: Normal * Backport: 2.7: REQUIRED, 3.0: REQUIRED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- I created PRs to fix CI failure for stable or old stable branches. * [Fix CI for ruby_2_7](https://github.com/ruby/ruby/pull/7259) * [Fix CI for ruby_3_0](https://github.com/ruby/ruby/pull/7258) * [Fix CI for ruby_3_2](https://github.com/ruby/ruby/pull/7604) Please merge them before release time. ---- Can I merge PR for "Fix CI failure" myself from April 2023? I can maintain to keep CI status with my full-time job. It helps to release work for all of branch maintainers. -- https://bugs.ruby-lang.org/

1 year, 1 month

2
2
0 0

[ruby-core:113051] [Ruby master Feature#19561] ObjectSpace::WeakMap#delete and ObjectSpace::WeakKeyMap#delete

by byroot (Jean Boussier)

Issue #19561 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #19561: ObjectSpace::WeakMap#delete and ObjectSpace::WeakKeyMap#delete https://bugs.ruby-lang.org/issues/19561 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- I just realized in https://bugs.ruby-lang.org/issues/19560#Ruby-shim that there's no way to remove elements from either WeakMaps. I think they could both benefit from a `delete` method. ### Use case For example, to keep track of a subset of instances of a class, you may need to remove some from the list when a condition changes: ```ruby class Connection CLOSE_ON_FORK = ObjectSpace::WeakMap.new class << self def after_fork CLOSE_ON_FORK.each_key do |connection| connection.close if connection.close_on_fork? end end end def close_on_fork=(enabled) if enabled CLOSE_ON_FORK[self] = true else CLOSE_ON_FORK.delete(self) end @close_on_fork = enabled end def close_on_fork? @close_on_fork end end module CloseOnFork IOS = ObjectSpace::WeakMap.new def _fork pid = super if pid == 0 # child ::Connection.after_fork end pid end end Process.singleton_class.prepend(CloseIOOnFork) ``` -- https://bugs.ruby-lang.org/

1 year, 1 month

2
1
0 0

[ruby-core:112933] [Ruby master Feature#19538] Performance warnings

by byroot (Jean Boussier)

Issue #19538 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #19538: Performance warnings https://bugs.ruby-lang.org/issues/19538 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- Suggested by @Eregon. There are program behaviors that are supported, but that we know aren't good for performance, however it's hard for users to know about them. Now that we have warning categories, we could add a `:performance` category to allow the VM to emit warning in some situations. The category would be disabled by default, and users interested in optimizing their program could turn it on in development. ```ruby Warning[:performance] = true ``` -- https://bugs.ruby-lang.org/

1 year, 1 month

5
10
0 0

[ruby-core:113060] [Ruby master Bug#19564] Range.cover? fails for Range wrapped in SimpleDelegator

by PeteMichaud (Pete Michaud)

Issue #19564 has been reported by PeteMichaud (Pete Michaud). ---------------------------------------- Bug #19564: Range.cover? fails for Range wrapped in SimpleDelegator https://bugs.ruby-lang.org/issues/19564 * Author: PeteMichaud (Pete Michaud) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby test 'built-in cover? method is broken for SimpleDelegator' do class TimeRangeDelegator < SimpleDelegator end t1 = Time.now t2 = t1+1.day t3 = t1+1.week r_long = t1..t3 r_short = t1..t2 assert r_long.cover?(r_short) #passes correctly, assert == true r_long_delegated = TimeRangeDelegator.new(r_long) r_short_delegated = TimeRangeDelegator.new(r_short) assert r_long_delegated.cover?(r_short_delegated) #fails incorrectly, assert == false end ``` -- https://bugs.ruby-lang.org/

1 year, 1 month

3
2
0 0

[ruby-core:112818] [Ruby master Misc#19525] DevMeeting-2023-04-13

by mame (Yusuke Endoh)

Issue #19525 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19525: DevMeeting-2023-04-13 https://bugs.ruby-lang.org/issues/19525 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/04/13 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 2023/04/10. 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/

1 year, 1 month

7
7
0 0

[ruby-core:111780] [Ruby master Bug#19331] --enable-rpath results in incorrect RPATH in Ruby 3.1.3

by Kulikjak (Jakub Kulik)

Issue #19331 has been reported by Kulikjak (Jakub Kulik). ---------------------------------------- Bug #19331: --enable-rpath results in incorrect RPATH in Ruby 3.1.3 https://bugs.ruby-lang.org/issues/19331 * Author: Kulikjak (Jakub Kulik) * Status: Open * Priority: Normal * ruby -v: 3.1.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I just updated Ruby from 3.1.2 to 3.1.3 and found out that all .so libraries from the enc directory have wrong RPATH/RUNPATH (when building with `--enable-rpath`). I first hit this on Solaris, but my testing on Linux resulted in the same thing. It can be easily reproduced with the following: ``` wget http://cache.ruby-lang.org/pub/ruby/3.1/ruby-3.1.3.tar.gz tar xzf ruby-3.1.3.tar.gz cd ruby-3.1.3 ./configure --prefix=/usr/ruby/3.1 --mandir=/usr/ruby/3.1/share/man --bindir=/usr/ruby/3.1/bin --sbindir=/usr/ruby/3.1/sbin --libdir=/usr/ruby/3.1/lib/amd64 --with-rubylibprefix=/usr/ruby/3.1/lib/ruby --enable-shared --enable-rpath /usr/bin/make -j 16 -l 32 objdump -x ./.ext/x86_64-linux/enc/windows_31j.so | grep RPATH ``` While previously this resulted in the following output: `RPATH /usr/ruby/3.1/lib/amd64` in 3.1.3 it is wrongly set to the build directory: `RPATH /home/jkulik/rubytest/ruby-3.1.3` I tried looking for some obvious change but didn't find the core of this issue yet. All I found out is that generated `enc.mk` differs in `prefix` and `libdir` ``` -prefix = /usr/ruby/3.1 +prefix = /home/jkulik/rubytest/ruby-3.1.3 exec_prefix = $(prefix) -libdir = $(exec_prefix)/lib/amd64 +libdir = /home/jkulik/rubytest/ruby-3.1.3 ``` `rbconfig.rb` is similar in both versions, but when I print out `CONFIG` in `make_encmake.rb` right after `load File.expand_path("lib/mkmf.rb", dir)`, I can see the differences from above, so it's probably something in the `lib/mkmf.rb` file that changes that. I am seeing the same issue in the current latest ruby 3.1 branch cloned from github. -- https://bugs.ruby-lang.org/

1 year, 1 month

3
4
0 0

[ruby-core:113059] [Ruby master Bug#19563] Ripper.tokenize(code).join != code when heredoc and multiline %w[] literal is on the same line

by tompng (tomoya ishida)

Issue #19563 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19563: Ripper.tokenize(code).join != code when heredoc and multiline %w[] literal is on the same line https://bugs.ruby-lang.org/issues/19563 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-03-29T21:57:52Z master 1b06422767) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ~~~ruby Ripper.tokenize "<<EOF || %w[hello\nEOF\n\n\n\nworld]" # actual result ["<<EOF", " ", "||", " ", "%w[", "hello", "\n\n\n\n", "EOF\n", "world", "]"] # expected result ["<<EOF", " ", "||", " ", "%w[", "hello", "\n", "EOF\n", "\n\n\n", "world", "]"] ~~~ same for `%i[]` literal. -- https://bugs.ruby-lang.org/

1 year, 1 month

3
5
0 0

[ruby-core:111956] [Ruby master Bug#19363] Fix rb_transient_heap_mark: wrong header (T_STRUCT) segfault

by bkuhlmann (Brooke Kuhlmann)

Issue #19363 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Bug #19363: Fix rb_transient_heap_mark: wrong header (T_STRUCT) segfault https://bugs.ruby-lang.org/issues/19363 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22.2.0] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## Overview Hello. 👋 I'm hitting an issue where my build is constantly failing with a segfault. The following is a snippet taken from my local machine with YJIT enabled (see attachments for details): ``` /Users/bkuhlmann/.cache/frum/versions/3.2.0/lib/ruby/gems/3.2.0/gems/puma-6.0.2/lib/puma/runner.rb: [BUG] rb_transient_heap_mark: wrong header, T_STRUCT (0x0000000109ea98a0) ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22.2.0] ``` The closest issue I could find that might be related to this issue (but not sure) is this issue: #15358. ## Steps to Recreate You should be able to quickly recreate this issue via these steps: - Download/clone my [Hemo](https://github.com/bkuhlmann/hemo) project. - Run the setup steps. - Run the test suite by running `bin/rspec`. If you need an example of the same segfault (but not on my macOS machine), you can see the same segfault via my [Circle CI Build](https://app.circleci.com/pipelines/github/bkuhlmann/hemo/11/workflow…. My Circle CI build is using my [Docker Alpine Linux Ruby](https://www.alchemists.io/projects/docker-alpine-ruby) image which might be of interest as well. This Docker image is also built with YJIT enabled. Interestingly, is if you were to run the test suite with `bin/guard` instead of `bin/rspec` then the segfault doesn't occur. ## Environment ``` ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [arm64-darwin22.2.0] 1.43.0 (using Parser 3.2.0.0, rubocop-ast 1.24.1, running on ruby 3.2.0) [arm64-darwin22.2.0] - rubocop-performance 1.15.2 - rubocop-rake 0.6.0 - rubocop-rspec 2.18.1 - rubocop-sequel 0.3.4 - rubocop-thread_safety 0.4.4 ``` ---Files-------------------------------- segfault.txt (237 KB) ruby-2023-01-21-113841.ips (19.6 KB) -- https://bugs.ruby-lang.org/

1 year, 1 month

6
8
0 0

[ruby-core:113064] [Ruby master Bug#19566] OptionParser::on raises unsupported argument type: URI (ArgumentError) but shouldn't

by jgomo3

Issue #19566 has been reported by jgomo3 (Jesús Gómez). ---------------------------------------- Bug #19566: OptionParser::on raises unsupported argument type: URI (ArgumentError) but shouldn't https://bugs.ruby-lang.org/issues/19566 * Author: jgomo3 (Jesús Gómez) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The documentation says > OptionParser comes with a few ready-to-use kinds of type coercion. They are > .. > * URI – Anything accepted by URI.parse > But when I try to use the class `URI` as a coercion class: ``` op = OptionParser.new op.on("--uri URI", URI) ``` I get: `unsupported argument type: URI (ArgumentError)`. The workaround is to register it with `accept`: ``` op = OptionParser.new op.accept(URI, &URI.method(:parse)) op.on("--uri URI", URI) ``` I attached 2 files, the first one `ruby-op-uri-bug.rb` displays the Error. The second one, `ruby-op-uri-workaround.rb` show the proper output. ---Files-------------------------------- ruby-op-uri-bug.rb (340 Bytes) ruby-op-uri-bug-workaround.rb (377 Bytes) -- https://bugs.ruby-lang.org/

1 year, 1 month

3
2
0 0

2024

2023

2022

ruby-core March 2023