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

[ruby-core:118328] [Ruby master Bug#20582] Directory not empty
by wzh4464 (Zihan Wu) 16 Jun '24

16 Jun '24

Issue #20582 has been reported by wzh4464 (Zihan Wu). ---------------------------------------- Bug #20582: Directory not empty https://bugs.ruby-lang.org/issues/20582 * Author: wzh4464 (Zihan Wu) * Status: Open * ruby -v: ruby 3.3.3 (2024-06-12 revision f1c7b6f435) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- #### Summary When running `brew upgrade ruby`, several directories encountered the error: `Error: Directory not empty @ dir_s_rmdir /private/tmp/xxx`. After inspection, it was found that these directories contained `.DS_Store` files. #### Reproduce Process 1. **System Details:** - **OS Version:** macOS 14.5 (23F79) - **Chip:** Apple Silicon M1 2. **Steps to Reproduce:** 1. Ensure Homebrew is installed and up to date. 2. Run the following command to upgrade Ruby: ```sh brew upgrade ruby ``` 3. Observe the error during the upgrade process. #### Result of Reproduce Process During the upgrade process, several directories failed to be removed due to the presence of `.DS_Store` files. The specific error encountered was: ``` Error: Directory not empty @ dir_s_rmdir /private/tmp/homebrew-unpack20240616-1699-7vglx8/ruby/3.3.3/lib/ruby/gems/3.3.0 ``` #### Expected Result The expected result is a successful upgrade of Ruby without encountering any errors related to directory removal. The upgrade process should handle the presence of hidden files like `.DS_Store` and proceed without interruptions. #### Additional Information - **Ruby Version:** 3.3.3 - **Homebrew Version:** Homebrew 4.3.5-118-g766b9b8 - **Logs and Output:** The error logs indicating the presence of `.DS_Store` files in the temporary directories. #### Steps Taken to Resolve - Manually checked and confirmed the presence of `.DS_Store` files in the directories mentioned in the error logs. - Removed `.DS_Store` files manually and retried the upgrade process. #### Suggested Fix To prevent such errors in the future, the upgrade script should handle the presence of hidden files like `.DS_Store` and ensure they do not block the directory removal process. Adding a step to ignore or remove these files during cleanup would be beneficial. #### Maintainer Assignment Since this issue is encountered on macOS, it may be relevant to assign it to the current maintainer for macOS-related issues. #### Thank you! Thank you for your attention to this issue. Looking forward to a resolution. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117918] [Ruby master Bug#20494] Non-default directories are not searched when checking for a gmp header
by lish82 (Hiroki Katagiri) 15 Jun '24

15 Jun '24

Issue #20494 has been reported by lish82 (Hiroki Katagiri). ---------------------------------------- Bug #20494: Non-default directories are not searched when checking for a gmp header https://bugs.ruby-lang.org/issues/20494 * Author: lish82 (Hiroki Katagiri) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This is my very first issue submission I would be happy to know if I missed anything --- I found that the ruby installed with `ruby-build` is not linked to the gmp library Environment: - OS: macOS Sonoma 14.5 - Directory that gmp is installed: /opt/homebrew (= installed via homebrew) I believe it was able to link to gmp before, so I tried to investigate the cause of the problem As a result, I found the followings: - During the execution of `./configure`, `checking for gmp.h...` is showing `no` - Specifying `--with-gmp-dir=/opt/homebrew` does not work - It has been occurring since 3.2.3 - When I built it on linux, it was successfully linked to gmp - gmp was installed in the default directory (`/usr/include`) - Revert the following changes and the problem goes away - https://github.com/ruby/ruby/pull/8449 Based on these observations, I believe the issue is that the directories specified with `--with-opt-dir` or `--with-gmp-dir` are not being included in the search path when checking for the gmp header I was able to solve the problem by changing the build process as follows ```patch diff --git a/configure.ac b/configure.ac index 18b4247..a440de6 100644 --- a/configure.ac +++ b/configure.ac @@ -1363,7 +1363,11 @@ AS_CASE("$target_cpu", [x64|x86_64|i[3-6]86*], [ RUBY_UNIVERSAL_CHECK_HEADER([x86_64, i386], x86intrin.h) AS_IF([test "x$with_gmp" != xno], - [AC_CHECK_HEADERS(gmp.h) + [original_CPPFLAGS="${CPPFLAGS}" + CPPFLAGS="${INCFLAGS} ${CPPFLAGS}" + AC_CHECK_HEADERS(gmp.h) + CPPFLAGS="${original_CPPFLAGS}" + unset original_CPPFLAGS AS_IF([test "x$ac_cv_header_gmp_h" != xno], AC_SEARCH_LIBS([__gmpz_init], [gmp], [AC_DEFINE(HAVE_LIBGMP, 1)]))]) ``` However, I am not familiar with ruby's build process or autotools, so I'm not sure if this is the correct approach --- I would appreciate it if someone could consider resolving this issue -- https://bugs.ruby-lang.org/

7 9

[ruby-core:118110] [Ruby master Bug#20515] --with-gmp is not working - GMP support won't be built
by sorah (Sorah Fukumori) 15 Jun '24

15 Jun '24

Issue #20515 has been reported by sorah (Sorah Fukumori). ---------------------------------------- Bug #20515: --with-gmp is not working - GMP support won't be built https://bugs.ruby-lang.org/issues/20515 * Author: sorah (Sorah Fukumori) * Status: Open * Assignee: sorah (Sorah Fukumori) * Target version: 3.3 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- gmp integration has been broken since https://bugs.ruby-lang.org/issues/20494 18eaf0be905e3e251423b42d6f4e56b7cae1bc3b including just released 3.3.2 due to missing HAVE_GMP_H. -- https://bugs.ruby-lang.org/

3 7

[ruby-core:117905] [Ruby master Bug#20493] Segfault on rb_io_getline_fast
by josegomezr (Jose Gomez) 15 Jun '24

15 Jun '24

Issue #20493 has been reported by josegomezr (Jose Gomez). ---------------------------------------- Bug #20493: Segfault on rb_io_getline_fast https://bugs.ruby-lang.org/issues/20493 * Author: josegomezr (Jose Gomez) * Status: Open * ruby -v: 3.3.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- We've spotted a consistent segfault when running bundle install with `--jobs 4` When running: `bundle install -j 4` we'd get a Segfault at: ``` /usr/lib64/ruby/3.3.0/rubygems/ext/builder.rb:93: [BUG] Segmentation fault at 0x0000000000000014 ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux-gnu] ``` Full [log is available here][0]. I could not find a shorter reproducer besides using bundler with `--jobs 4` or `--jobs 8`. Here's a sample command to trigger the behavior (it creates the Gemfile and calls bundler) [1]. We installed all debug symbols and narrowed down the location of the segfault to `rb_io_getline_fast` in io.c At [line 4001][3] `str` is `T_NONE`, which makes further usage down the line in [`io_enc_str`][4] raise a null pointer dereference. With the notes from [extension.rdoc - Appendix E. RB_GC_GUARD to protect from premature GC][8] I've prepared a patched ruby 3.3.1 package that does not segfault. It's on [OBS Project home:josegomezr:branches:ruby/ruby3.3][6]. Adding a `RB_GC_GUARD` on `rb_io_getline_fast` @ `io.c:4004` just before the return ```diff --- ruby3.3.orig/ruby-3.3.1/io.c +++ ruby3.3/ruby-3.3.1/io.c @@ -4004,6 +4004,7 @@ rb_io_getline_fast(rb_io_t *fptr, rb_enc ENC_CODERANGE_SET(str, cr); fptr->lineno++; + RB_GC_GUARD(str); return str; } ``` Fixes the segfault in our tests. `bundle` finish the installation and the image is built. I've set up a project in OBS to provide reproduceables. - [ruby3.3.1 package][5]. - [ruby3.3.1 base image with enough dependencies to reproduce][7] with [the reproducer script][1]. And the corresponding container is exported in the `containers-patched` repository. Here I leave the docker images generated by OBS: - 3.3.1 [without patches, segfaults.] ``` registry.opensuse.org/home/josegomezr/branches/ruby/containers/containers/b… ``` - 3.3.1 [with patch, does not fail] ``` registry.opensuse.org/home/josegomezr/branches/ruby/containers/containers-p… ``` [0]: https://gist.github.com/josegomezr/441c271cc731b0ec57213cb98743a699 [1]: https://gist.github.com/josegomezr/e17129bf2df33f3bea60e84a616a8322 [2]: https://gist.github.com/josegomezr/6f81878c979af334efee59b8f2225e58 [3]: https://github.com/ruby/ruby/blob/v3_3_1/io.c#L4001 [4]: https://github.com/ruby/ruby/blob/v3_3_1/io.c#L4003 [5]: https://build.opensuse.org/package/show/devel:languages:ruby/ruby3.3 [6]: https://build.opensuse.org/package/show/home:josegomezr:branches:ruby/ruby3… [7]: https://build.opensuse.org/package/show/home:josegomezr:branches:ruby:conta… [8]: https://github.com/ruby/ruby/blob/master/doc/extension.rdoc#label-Appendix+… -- https://bugs.ruby-lang.org/

4 13

[ruby-core:116182] [Ruby master Bug#20180] Inconsistent evaluation of `**{}` depending on position in array
by ozydingo (Andrew Schwartz) 15 Jun '24

15 Jun '24

Issue #20180 has been reported by ozydingo (Andrew Schwartz). ---------------------------------------- Bug #20180: Inconsistent evaluation of `**{}` depending on position in array https://bugs.ruby-lang.org/issues/20180 * Author: ozydingo (Andrew Schwartz) * Status: Open * Priority: Normal * ruby -v: 3.3 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Reproduced on ruby:3.3 docker container The evaluation of `**{}` differs if it appears alone (evaluates as empty / no content) in an array vs after another element (evaluates as an empty Hash). ```rb args = []; kwargs = {} [*args] # => [] [**kwargs] # => [] [*args, **kwargs] # => [{}] [*args] + [**kwargs] == [*args, **kwargs] => false ``` I claim this violates the Principle of Least Surprise. I will admit that beyond a thin example I will give below, I am struggling to come up with a more convincing pragmatic reason that this should be addressed, but due to how surprising it is and the bugs it cause our team I wanted to submit it for tracking. This may be related to https://bugs.ruby-lang.org/issues/20064?tab=notes though the issues are distinct. Specifically, in my use case, I am writing a class responsible for adapting arguments in one form to another (json object to method args and vice versa). My tests broken when adding support for keyword args due to expectations of no args: ``` # RSpec expect(foo).to have_received(:bar).with([]) # This now need `with([], {})` ``` Again, this is a bit thin as by itself this isn't problematic as I can add the `{}`. However, this does require that my test knows more about the implementation that it should. That is, my implementation might be ``` if kwargs.present? call(*args, **kwargs) else call(*args) end ``` This change does not change the behavior of the class, but will break the test. I therefore think this behavior of `**kwargs` is problematic. -- https://bugs.ruby-lang.org/

6 7

[ruby-core:118268] [Ruby master Bug#20569] Instruction sequence generated from `shareable_constant_value: literal` files may not be serialized to binary
by byroot (Jean Boussier) 15 Jun '24

15 Jun '24

Issue #20569 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20569: Instruction sequence generated from `shareable_constant_value: literal` files may not be serialized to binary https://bugs.ruby-lang.org/issues/20569 * Author: byroot (Jean Boussier) * Status: Open * Assignee: ko1 (Koichi Sasada) * Backport: 3.1: WONTFIX, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- ```ruby iseq = RubyVM::InstructionSequence.compile(<<~'RUBY') # shareable_constant_value: literal REGEXP = /#{}/ RUBY iseq.to_binary ``` ``` in `to_binary': ibf_dump_object_unsupported: 0x00000001026ac8b0 [3LM ] T_ICLASS (NotImplementedError) ``` The reason is that the ISeq contains `putobject RubyVM::FrozenCore` so `compile.c` need some special handling of that hidden class. Proposed patch: https://github.com/ruby/ruby/pull/10951 -- https://bugs.ruby-lang.org/

3 3

[ruby-core:116838] [Ruby master Bug#20280] Error at invalid encoding symbols
by nobu (Nobuyoshi Nakada) 15 Jun '24

15 Jun '24

Issue #20280 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20280: Error at invalid encoding symbols https://bugs.ruby-lang.org/issues/20280 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- Parsing an invalid encoding symbol raises an `EncodingError`. It must be a `SyntaxError`. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:118315] [Ruby master Bug#20579] `Ripper.tokenize("1\n ")` does not include trailing spaces
by tompng (tomoya ishida) 13 Jun '24

13 Jun '24

Issue #20579 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20579: `Ripper.tokenize("1\n ")` does not include trailing spaces https://bugs.ruby-lang.org/issues/20579 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.0dev (2024-06-13T09:49:46Z master 8b843b0dc7) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ~~~ruby # trailing :on_sp, :on_ignored_nl are included in the result Ripper.tokenize("1\n\t \t\n\t \t") # => ["1", "\n", "\t \t", "\n", "\t \t"] # trailing :on_sp disappears Ripper.tokenize("1\n\t \t") # => ["1", "\n"] ~~~ Found with `Ripper.tokenize(random_string).join != random_string` while investigating https://bugs.ruby-lang.org/issues/20578 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118314] [Ruby master Bug#20578] Tokenizing string literal that have newline and invalid escape is wrong
by tompng (tomoya ishida) 13 Jun '24

13 Jun '24

Issue #20578 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20578: Tokenizing string literal that have newline and invalid escape is wrong https://bugs.ruby-lang.org/issues/20578 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.0dev (2024-06-13T09:49:46Z master 8b843b0dc7) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Tokenizing string literal that have newline and invalid escape is wrong When a string literal includes `\n` and an invalid escape after it, tokenize result gets wrong. ~~~ruby Ripper.tokenize "\"hello\\x world" # => ["\"", "hello\\x", " world"] # looks good Ripper.tokenize "\"\nhello\\x world" # => ["\"", "\n world", "hello\\x"] # order is reversed ~~~ These invalid escapes also gets wrong ~~~ruby Ripper.tokenize("\"\n\\Cxx\"") #=> ["\"", "\nx", "\\Cx", "\""] Ripper.tokenize("\"\n\\Mxx\"") #=> ["\"", "\nx", "\\Mx", "\""] Ripper.tokenize("\"\n\\c\\cx\"") #=> ["\"", "\nx", "\\c\\c", "\""] Ripper.tokenize("\"\n\\ux\"") #=> ["\"", "\nx", "\""] Ripper.tokenize("\"\n\\xx\"") #=> ["\"", "\nx", "\\x", "\""] ~~~ And these literals also gets wrong ~~~ruby Ripper.tokenize("<<A\n\n\\xyz") #=> ["<<A", "\n", "\nyz", "\\x"] Ripper.tokenize("%(\n\\xyz)") #=> ["%(", "\nyz", "\\x", ")"] Ripper.tokenize("%Q(\n\\xyz)") #=> ["%Q(", "\nyz", "\\x", ")"] Ripper.tokenize(":\"\n\\xyz\"") #=> [":\"", "\nyz", "\\x", "\""] ~~~ I encountered this while typing a valid string literal into IRB ~~~ruby irb(main):001> " irb(main):002> \x█ ~~~ Other invalid escape sequence that disappears from tokenize result ~~~ruby Ripper.tokenize('"\u{123') # => ["\""] ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118267] [Ruby master Misc#20568] Look for test.rb in the current working directory
by eightbitraptor (Matthew Valentine-House) 12 Jun '24

12 Jun '24

Issue #20568 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Misc #20568: Look for test.rb in the current working directory https://bugs.ruby-lang.org/issues/20568 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open ---------------------------------------- [Github PR link](https://github.com/ruby/ruby/pull/10950) The `test.rb` script used by `make run` etc is explicitly located in the `$srcdir` - the location of the Ruby source code. The [Building Ruby](https://docs.ruby-lang.org/en/master/contributing/building_ruby_md.ht… documentation recommends using out-of-source builds. Requiring `test.rb` to be located in the source directory prevents me from having multiple build directories, with a distinct `test.rb` per build, instead forcing pollution of the source directory. I propose looking for `test.rb` in the current working directory. This will maintain compatibility with in-source builds, and provide extra flexibility for those of us using out-of-source builds. There will be a small one time impact for Ruby committers, who will have to move their existing `test.rb` files into their build directories. -- https://bugs.ruby-lang.org/

2 1