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

[ruby-core:111702] [Ruby master Bug#18797] Third argument to Regexp.new is a bit broken
by Eregon (Benoit Daloze) 06 Jan '23

06 Jan '23

Issue #18797 has been updated by Eregon (Benoit Daloze). Assignee set to jeremyevans0 (Jeremy Evans) Target version set to 3.3 ---------------------------------------- Bug #18797: Third argument to Regexp.new is a bit broken https://bugs.ruby-lang.org/issues/18797#change-101098 * Author: janosch-x (Janosch Müller) * Status: Open * Priority: Normal * Assignee: jeremyevans0 (Jeremy Evans) * Target version: 3.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- ## Situation 'n' or 'N' can be passed as a third argument to `Regexp.new`. However, the behavior is not the same as the literal `n`-flag or the `Regexp::NOENCODING` option, and it makes the `#encoding` of `Regexp` and `Regexp#source` diverge: ```ruby /😅/n # => SyntaxError Regexp.new('😅', Regexp::NOENCODING) # => RegexpError re = Regexp.new('😅', nil, 'n') # => /😅/ re.options == Regexp::NOENCODING # => true re.encoding # => ASCII-8BIT re.source.encoding # => UTF-8 re =~ '😅' # => Encoding::CompatibilityError ``` ## Code [Here](https://github.com/ruby/ruby/blob/b41de3a1e8c36a5cc336b6f7cd3cb71126c…. There is also a test for the resulting encoding [here](https://github.com/ruby/ruby/blob/cf2bbcfff2985c116552967c7c4522f4630…, but it is a no-op because the whole file is set to that encoding via magic comment anyway. The third argument was added when ASCII was still the default Ruby encoding, so I guess Regexp and source encoding still matched at that point. ## Solution It could be fixed, but my impression is that it is not useful anymore. It was probably only added because `Regexp::NOENCODING` wasn't available at the time, so I think it could be deprecated like so: > Passing a third argument to Regexp.new is deprecated. Use `Regexp::NOENCODING` as second argument instead. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111697] [Ruby master Feature#18949] Deprecate and remove replicate and dummy encodings
by Eregon (Benoit Daloze) 06 Jan '23

06 Jan '23

Issue #18949 has been updated by Eregon (Benoit Daloze). Target version set to 3.3 This is all done now, only https://github.com/ruby/ruby/pull/7079 left and I'll merge that when it passes CI. Overall: * We deprecated and removed `Encoding#replicate` * We removed `get_actual_encoding()` * We limited to 256 encodings and kept `rb_define_dummy_encoding()` with that constraint. * There is a single flat array to lookup encodings, `rb_enc_from_index()` is fast now. Since the limit is 256 and not 128 though it means `ENCODING_GET` is not just `RB_ENCODING_GET_INLINED` but still has the check and slow fallback. Thank you for the discussion, @ko1 for implementing the fixed-size table and let's close this. Of course for all builtin encodings the cost is just the extra check. Maybe the limit could be changed later to 128 if this optimization is wanted. ---------------------------------------- Feature #18949: Deprecate and remove replicate and dummy encodings https://bugs.ruby-lang.org/issues/18949#change-101095 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Assignee: Eregon (Benoit Daloze) * Target version: 3.3 ---------------------------------------- Ruby has a lot of accidental complexity. Sometimes it becomes clear some features bring a lot of complexity and yet provide little value or are used very rarely. Also most Ruby users do not even know about these features. Replicate and dummy encodings seem to clearly fall into this category, almost nobody uses them but they add a significant complexity and also add a significant performance overhead. Notably, the existence of those means the number of encodings in a Ruby runtime is actually variable and not fixed. That means extra synchronization, hashtable lookups, indirections, function calls, etc. ## Replicate Encodings Replicate encodings are created using `Encoding#replicate(name)`. It almost sounds like an alias but in fact it is more than that and creates a new Encoding object, which can be used by a String: ```ruby e = Encoding::US_ASCII.replicate('MY-US-ASCII') s = "abc".force_encoding(e) p s.encoding # => e p s.encoding.name # => 'MY-US-ASCII' ``` This seems completely useless. There is an obvious first step here which is to change `Encoding#replicate` to return the receiver, and just install an alias for it. That avoids creating more encoding instances needlessly. I think we should also deprecate and remove this method though, it is never a good idea to have a global mutable map like this. If someone want extra aliases for encodings, they can easily to do so by having their own Hash: `{ alias => encoding }.fetch(name) { Encoding.find(name) }`. ## Dummy Encodings Dummy encodings are not real encodings. They are artificial encodings designed to look like encodings, but don't function as encodings in Ruby. From the docs: ``` enc.dummy? -> true or false ------------------------------------------------------------------------ Returns true for dummy encodings. A dummy encoding is an encoding for which character handling is not properly implemented. It is used for stateful encodings. ``` I wonder why we have those half-implemented encodings in core, it sounds to me like unfinished work which should not have been merged. The "codepoints" of dummy encodings are just "bytes" and so they behave the same as `Encoding::BINARY`, with the exception of the UTF-16 and UTF-32 dummy encodings. ### UTF-16 and UTF-32 dummy encodings These two are special dummy encodings. What they do is they scan the first 2 or 4 bytes of the String, and if those bytes are a byte-order mark (BOM), the true "actual" encoding is resolved to UTF-16BE/UTF-16LE or UTF-32BE/UTF-32LE. Otherwise, `Encoding::BINARY` is returned. This logic is done by `get_actual_encoding()`. What is weird is this check is not done on String creation, no, it is done *every time* the encoding of that String is accessed (and the result is not stored on the String). That is a needless overhead and really unreliable semantics. Do we really want a String which automagically changes between UTF-16LE and UTF-16BE based on mutating its bytes? I think nobody wants that: ```ruby s = "\xFF\xFEa\x00b\x00c\x00d\x00".force_encoding("UTF-16") p s # => "\uFEFFabcd" s.setbyte 0, 254 s.setbyte 1, 255 p s # => "\uFEFF\u6100\u6200\u6300\u6400" ``` I think the path is clear, we should deprecate and then remove Encoding::UTF_16 and Encoding::UTF_32 (dummy encodings). And then we no longer need `get_actual_encoding()` and the overhead it adds to every String method. We could also keep those constants and make them refer the native-endian UTF-16/32. But that could cause confusing errors as we would change the meaning of them. We could add `Encoding::UTF_16NE` / `Encoding::UTF_16_NATIVE_ENDIAN` if that is useful. Another possibility would be to resolve these encodings on String creation, like: ``` "\xFF\xFE".force_encoding("UTF-16").encoding # => UTF-16LE String.new("\xFF\xFE", encoding: Encoding::UTF_16).encoding # => UTF-16LE "ab".force_encoding("UTF-16").encoding # exception, not a BOM String.new("ab", encoding: Encoding::UTF_16).encoding # exception, not a BOM ``` I think it is unnecessary to keep such complexity though. A class method on String or Encoding like e.g. `Encoding.find_from_bom(string)` is so much clearer and efficient (no need to special case those encodings in String.new, #force_encoding, etc). FWIW JRuby seems to use `getActualEncoding()` only in 2 places (scanForCodeRange, inspect), which is an indication those dummy UTF encodings are barely used if ever. Similarly, TruffleRuby only has 4 usages of `GetActualEncodingNode`. ### Existing dummy encodings ``` > Encoding.list.select(&:dummy?) [#<Encoding:UTF-16 (dummy)>, #<Encoding:UTF-32 (dummy)>, #<Encoding:IBM037 (dummy)>, #<Encoding:UTF-7 (dummy)>, #<Encoding:ISO-2022-JP (dummy)>, #<Encoding:ISO-2022-JP-2 (dummy)>, #<Encoding:ISO-2022-JP-KDDI (dummy)>, #<Encoding:CP50220 (dummy)>, #<Encoding:CP50221 (dummy)>] ``` So besides UTF-16/UTF-32 dummy, it's only 7 encodings. Does anyone use one of these 7 dummy encodings? What is interesting to note, is that these encodings are exactly the ones that are also not ASCII-compatible, with the exception of UTF-16BE/UTF-16LE/UTF-32BE/UTF-32LE (non-dummy). As a note, UTF-{16,32}{BE,LE} are ASCII-compatible in codepoints but not in bytes, and Ruby uses the bytes definition of ASCII-compatible. There is potential to simplify encoding compatibility rules and encoding compatibility checks based on that. So what this means is if we removed dummy encodings, all encodings except UTF-{16,32}{BE,LE} would be ASCII-compatible, which would lead to significant simplifications for many string operations which currently need to handle dummy encodings specially. Unicode encodings like UTF-{16,32}{BE,LE} already have special behavior for some Ruby methods, so those are already handled specially in some places (they are the only encodings with minLength > 1). ``` > Encoding.list.reject(&:ascii_compatible?) [#<Encoding:UTF-16BE>, #<Encoding:UTF-16LE>, #<Encoding:UTF-32BE>, #<Encoding:UTF-32LE>, #<Encoding:UTF-16 (dummy)>, #<Encoding:UTF-32 (dummy)>, #<Encoding:IBM037 (dummy)>, #<Encoding:UTF-7 (dummy)>, #<Encoding:ISO-2022-JP (dummy)>, #<Encoding:ISO-2022-JP-2 (dummy)>, #<Encoding:ISO-2022-JP-KDDI (dummy)>, #<Encoding:CP50220 (dummy)>, #<Encoding:CP50221 (dummy)>] ``` What can we do with such a dummy non-ASCII-compatible encoding? Almost nothing useful: ```ruby s = "abc".encode("IBM037") => "\x81\x82\x83" > s.bytes => [129, 130, 131] > s.codepoints => [129, 130, 131] > s == "abc" => false > "été".encode("IBM037") => "\x51\xA3\x51" ``` So about the only thing that works with them is `String#encode`. I think we could preserve that functionality, if actually used (does anyone use one of these 7 dummy encodings?), through: ```ruby > "été".encode("IBM037") => "\x51\xA3\x51" (.encoding == BINARY) > "\x51\xA3\x51".encode("UTF-8", "IBM037") # encode from IBM037 to UTF-8 => "été" (.encoding == UTF-8) ``` That way there is no need for those to be Encoding instances, we would only need the conversion tables. It is even better if we can remove them, so the notion of "dummy encodings" can disappear completely and nobody needs to understand or implement them. ### rb_define_dummy_encoding(name) The C-API has `rb_define_dummy_encoding(const char *name)`. This creates a new Encoding instance with `dummy?=true`, and it is also non-ASCII-compatible. There seems to be no purpose to this besides storing the metadata of an encoding which does not exist in Ruby. This seems a really expensive/complex way to handle that from the VM point of view (because it dynamically creates an Encoding and add it to lists/maps/etc). A simple replacement would be to mark the String as BINARY and save the encoding name as an instance variable of that String. Since anyway Ruby can't understand anything about that String, it's just raw bytes to Ruby's eyes. ## Summary I suggest we deprecate replicate and dummy encodings in Ruby 3.2. And then we remove them in the next version. This will significantly simplify string-related methods, and the behavior exposed to Ruby users. It will also significantly speedup encoding lookup in CRuby (and other Ruby implementations). With a fixed number of encodings we can ensure all encoding indices fit in 7 bits, and `ENCODING_GET` can be simply `RB_ENCODING_GET_INLINED`. `get_actual_encoding()` will be gone and its overhead as well. `rb_enc_from_index()` would be just `return global_enc_table->list[index].enc;`, instead of the expensive behavior currently with `GLOBAL_ENC_TABLE_EVAL` which takes a lock and more when there are multiple Ractors. Many checks in these methods would be removed as well. Yet another improvement would be to load all encodings eagerly, that is small and fast in my experience, what is slow and big is the conversion tables, that'd simplify `must_encindex()` further. These changes would affect most String methods, which use ``` STR_ENC_GET->get_encoding which does: get_actual_encoding->rb_enc_from_index and possibly ->enc_from_index ENCODING_GET->RB_ENCODING_GET_INLINED and possibly ->rb_enc_get_index->enc_get_index_str->rb_attr_get ``` Some of these details are mentioned in https://github.com/ruby/ruby/pull/6095#discussion_r915149708. The overhead is so large that it is worth handling some hardcoded encoding indices directly in String methods. This feels wrong, getting the encoding from a String should be simple, straightforward and fast. Further optimizations will be unlocked as the encoding list becomes fixed and immutable. For example, the name-to-Encoding map is then immutable and could use perfect hashing. Inline caching those lookups also becomes easier as the the map cannot change. Also that map would no longer need synchronization, etc. ## To Decide Each item is independent. I think 1 & 2 are very important, 3 less but would be nice. 1. Deprecate and then remove `Encoding#replicate` and `rb_define_dummy_encoding()`. With that there is a fixed number of encodings, a lot of simplifications and many optimizations become available. They are used respectively in only 1 gem and 5 gems, see https://bugs.ruby-lang.org/issues/18949#note-4 2. Deprecate and then remove the dummy UTF-16 and UTF-32 encodings. This removes the need for `get_actual_encoding()` which is expensive. This functionality seems rarely used in practice, and it only works when such strings have a BOM, which is very rare. 3. Deprecate and then remove other dummy encodings, so there are no more dummy "half-implemented" encodings and all encodings are ASCII-compatible in terms of codepoints. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111694] [Ruby master Bug#18518] NoMemoryError + [FATAL] failed to allocate memory for twice 1 << large
by Eregon (Benoit Daloze) 06 Jan '23

06 Jan '23

Issue #18518 has been updated by Eregon (Benoit Daloze). So on 32-bit platforms it already behaves as I would expect, from the log in https://bugs.ruby-lang.org/issues/19260?next_issue_id=19259&prev_issue_id=1… ```ruby 1 << (2**40) #=> RangeError (shift width too big) ``` I think a shift width over 32 signed bits is too much for all platforms, and it would be useful if the behavior in that regard is the same for all platforms. Nobody wants to wait a very long time only to get a NoMemoryError for such code, isn't it? ---------------------------------------- Bug #18518: NoMemoryError + [FATAL] failed to allocate memory for twice 1 << large https://bugs.ruby-lang.org/issues/18518#change-101093 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * ruby -v: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Repro: ```ruby exp = 2**40 # also fails with bignum e.g. 2**64 def exc begin yield rescue NoMemoryError => e p :NoMemoryError end end p exp exc { (1 << exp) } exc { (-1 << exp) } exc { (bignum_value << exp) } exc { (-bignum_value << exp) } ``` Output: ``` $ ruby -v mri_oom.rb ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] mri_oom.rb:7: warning: assigned but unused variable - e 1099511627776 :NoMemoryError [FATAL] failed to allocate memory ``` 3.1.0 seems fine: ``` $ ruby -v mri_oom.rb ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-linux] mri_oom.rb:7: warning: assigned but unused variable - e 1099511627776 :NoMemoryError :NoMemoryError :NoMemoryError :NoMemoryError ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111692] [Ruby master Bug#8973] Allow to configure archlibdir for multiarch
by vo.x (Vit Ondruch) 06 Jan '23

06 Jan '23

Issue #8973 has been updated by vo.x (Vit Ondruch). Actually, the real intention here is to get rid of the `${arch}` from the paths. The thing is that `--enable-multiarch` used to make it possible, because this is the implementation: ~~~ rubyarchprefix=${multiarch+'${archlibdir}/${RUBY_BASE_NAME}'}${multiarch-'${rubylibprefix}/${arch}'} ~~~ As you can see, when `multiarch` is not defined, then the `${arch}` is mandatory. With `multiarch` enabled, it is enough to modify the `${archlibdir}` and whatever is the is there. It does not impose any expectations. BTW out of curiosity, assuming that upstream expect that Ruby is installed via `./configure && make && make install`, what is the reason to bother with `${arch}` for non multiarch configurations? Does anybody really use single installation directory with multiple architectures? ---------------------------------------- Bug #8973: Allow to configure archlibdir for multiarch https://bugs.ruby-lang.org/issues/8973#change-101092 * Author: vo.x (Vit Ondruch) * Status: Feedback * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 2.1.0dev (2013-09-22 trunk 43011) [x86_64-linux] ---------------------------------------- Since r39347, there is impossible to configure placement of rubylib.so when build is configured with "--with-multiarch". That is probably OK for Debian, but it breaks Fedora :/ The attached patch allows to configure the archlibdir, but I feel that it is suboptimal, since the "--with-rubyarchprefix" should probably be the parameter which influences placement of the arch specific libraries. Any chance that this patch is accepted or better if rubyarchprefix is respected for every arch specific library, including libruby.so. Thanks. ---Files-------------------------------- ruby-2.1.0-Enable-configuration-of-archlibdir.patch (479 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111585] [Ruby master Bug#19302] Non-destructive String#insert
by noraj (Alexandre ZANNI) 06 Jan '23

06 Jan '23

Issue #19302 has been reported by noraj (Alexandre ZANNI). ---------------------------------------- Bug #19302: Non-destructive String#insert https://bugs.ruby-lang.org/issues/19302 * Author: noraj (Alexandre ZANNI) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- It would be nice to have a non-destructive version of String#insert to be able to work with frozen literals. ## Current behavior There is only a destructive version of `String#insert` that will throw an error if the string is frozen. ```ruby irb(main):007:0> a = 'foobar'.freeze irb(main):008:0> b = a.insert(3,'baz') (irb):8:in `insert': can't modify frozen String: "foobar" (FrozenError) from (irb):8:in `<main>' from /home/noraj/.asdf/installs/ruby/3.2.0/lib/ruby/gems/3.2.0/gems/irb-1.6.2/exe/irb:11:in `<top (required)>' from /home/noraj/.asdf/installs/ruby/3.2.0/bin/irb:25:in `load' from /home/noraj/.asdf/installs/ruby/3.2.0/bin/irb:25:in `<main>' ``` This can happen pretty quickly when you have `# frozen_string_literal: true` in all your files. ## Idea of implementation ```ruby def insert_nd(idx, str2) self[0...idx] + str2 + self[idx..] end ``` Note: this is a draft, as it doesn't handle negative index in the same way as insert ## Idea of naming Ideally the actual `String#insert` would have been `String#insert!` so that the non-destructive version could be `String#insert`, but naturally that won't do as a renaming will cause a breaking change. A more viable option would be to name it `insert_nd` (nd for non-destructive) but it's may not be following a naming convention. Another idea to avoid confusion would be to avoid using `insert` and rather use a synonym like _place_, _slip_, _slot_, _lodge_, etc. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:111690] [Ruby master Feature#18949] Deprecate and remove replicate and dummy encodings
by Eregon (Benoit Daloze) 06 Jan '23

06 Jan '23

Issue #18949 has been updated by Eregon (Benoit Daloze). @ko1 did https://github.com/ruby/ruby/pull/6935, great, thank you! ---------------------------------------- Feature #18949: Deprecate and remove replicate and dummy encodings https://bugs.ruby-lang.org/issues/18949#change-101090 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Assignee: Eregon (Benoit Daloze) ---------------------------------------- Ruby has a lot of accidental complexity. Sometimes it becomes clear some features bring a lot of complexity and yet provide little value or are used very rarely. Also most Ruby users do not even know about these features. Replicate and dummy encodings seem to clearly fall into this category, almost nobody uses them but they add a significant complexity and also add a significant performance overhead. Notably, the existence of those means the number of encodings in a Ruby runtime is actually variable and not fixed. That means extra synchronization, hashtable lookups, indirections, function calls, etc. ## Replicate Encodings Replicate encodings are created using `Encoding#replicate(name)`. It almost sounds like an alias but in fact it is more than that and creates a new Encoding object, which can be used by a String: ```ruby e = Encoding::US_ASCII.replicate('MY-US-ASCII') s = "abc".force_encoding(e) p s.encoding # => e p s.encoding.name # => 'MY-US-ASCII' ``` This seems completely useless. There is an obvious first step here which is to change `Encoding#replicate` to return the receiver, and just install an alias for it. That avoids creating more encoding instances needlessly. I think we should also deprecate and remove this method though, it is never a good idea to have a global mutable map like this. If someone want extra aliases for encodings, they can easily to do so by having their own Hash: `{ alias => encoding }.fetch(name) { Encoding.find(name) }`. ## Dummy Encodings Dummy encodings are not real encodings. They are artificial encodings designed to look like encodings, but don't function as encodings in Ruby. From the docs: ``` enc.dummy? -> true or false ------------------------------------------------------------------------ Returns true for dummy encodings. A dummy encoding is an encoding for which character handling is not properly implemented. It is used for stateful encodings. ``` I wonder why we have those half-implemented encodings in core, it sounds to me like unfinished work which should not have been merged. The "codepoints" of dummy encodings are just "bytes" and so they behave the same as `Encoding::BINARY`, with the exception of the UTF-16 and UTF-32 dummy encodings. ### UTF-16 and UTF-32 dummy encodings These two are special dummy encodings. What they do is they scan the first 2 or 4 bytes of the String, and if those bytes are a byte-order mark (BOM), the true "actual" encoding is resolved to UTF-16BE/UTF-16LE or UTF-32BE/UTF-32LE. Otherwise, `Encoding::BINARY` is returned. This logic is done by `get_actual_encoding()`. What is weird is this check is not done on String creation, no, it is done *every time* the encoding of that String is accessed (and the result is not stored on the String). That is a needless overhead and really unreliable semantics. Do we really want a String which automagically changes between UTF-16LE and UTF-16BE based on mutating its bytes? I think nobody wants that: ```ruby s = "\xFF\xFEa\x00b\x00c\x00d\x00".force_encoding("UTF-16") p s # => "\uFEFFabcd" s.setbyte 0, 254 s.setbyte 1, 255 p s # => "\uFEFF\u6100\u6200\u6300\u6400" ``` I think the path is clear, we should deprecate and then remove Encoding::UTF_16 and Encoding::UTF_32 (dummy encodings). And then we no longer need `get_actual_encoding()` and the overhead it adds to every String method. We could also keep those constants and make them refer the native-endian UTF-16/32. But that could cause confusing errors as we would change the meaning of them. We could add `Encoding::UTF_16NE` / `Encoding::UTF_16_NATIVE_ENDIAN` if that is useful. Another possibility would be to resolve these encodings on String creation, like: ``` "\xFF\xFE".force_encoding("UTF-16").encoding # => UTF-16LE String.new("\xFF\xFE", encoding: Encoding::UTF_16).encoding # => UTF-16LE "ab".force_encoding("UTF-16").encoding # exception, not a BOM String.new("ab", encoding: Encoding::UTF_16).encoding # exception, not a BOM ``` I think it is unnecessary to keep such complexity though. A class method on String or Encoding like e.g. `Encoding.find_from_bom(string)` is so much clearer and efficient (no need to special case those encodings in String.new, #force_encoding, etc). FWIW JRuby seems to use `getActualEncoding()` only in 2 places (scanForCodeRange, inspect), which is an indication those dummy UTF encodings are barely used if ever. Similarly, TruffleRuby only has 4 usages of `GetActualEncodingNode`. ### Existing dummy encodings ``` > Encoding.list.select(&:dummy?) [#<Encoding:UTF-16 (dummy)>, #<Encoding:UTF-32 (dummy)>, #<Encoding:IBM037 (dummy)>, #<Encoding:UTF-7 (dummy)>, #<Encoding:ISO-2022-JP (dummy)>, #<Encoding:ISO-2022-JP-2 (dummy)>, #<Encoding:ISO-2022-JP-KDDI (dummy)>, #<Encoding:CP50220 (dummy)>, #<Encoding:CP50221 (dummy)>] ``` So besides UTF-16/UTF-32 dummy, it's only 7 encodings. Does anyone use one of these 7 dummy encodings? What is interesting to note, is that these encodings are exactly the ones that are also not ASCII-compatible, with the exception of UTF-16BE/UTF-16LE/UTF-32BE/UTF-32LE (non-dummy). As a note, UTF-{16,32}{BE,LE} are ASCII-compatible in codepoints but not in bytes, and Ruby uses the bytes definition of ASCII-compatible. There is potential to simplify encoding compatibility rules and encoding compatibility checks based on that. So what this means is if we removed dummy encodings, all encodings except UTF-{16,32}{BE,LE} would be ASCII-compatible, which would lead to significant simplifications for many string operations which currently need to handle dummy encodings specially. Unicode encodings like UTF-{16,32}{BE,LE} already have special behavior for some Ruby methods, so those are already handled specially in some places (they are the only encodings with minLength > 1). ``` > Encoding.list.reject(&:ascii_compatible?) [#<Encoding:UTF-16BE>, #<Encoding:UTF-16LE>, #<Encoding:UTF-32BE>, #<Encoding:UTF-32LE>, #<Encoding:UTF-16 (dummy)>, #<Encoding:UTF-32 (dummy)>, #<Encoding:IBM037 (dummy)>, #<Encoding:UTF-7 (dummy)>, #<Encoding:ISO-2022-JP (dummy)>, #<Encoding:ISO-2022-JP-2 (dummy)>, #<Encoding:ISO-2022-JP-KDDI (dummy)>, #<Encoding:CP50220 (dummy)>, #<Encoding:CP50221 (dummy)>] ``` What can we do with such a dummy non-ASCII-compatible encoding? Almost nothing useful: ```ruby s = "abc".encode("IBM037") => "\x81\x82\x83" > s.bytes => [129, 130, 131] > s.codepoints => [129, 130, 131] > s == "abc" => false > "été".encode("IBM037") => "\x51\xA3\x51" ``` So about the only thing that works with them is `String#encode`. I think we could preserve that functionality, if actually used (does anyone use one of these 7 dummy encodings?), through: ```ruby > "été".encode("IBM037") => "\x51\xA3\x51" (.encoding == BINARY) > "\x51\xA3\x51".encode("UTF-8", "IBM037") # encode from IBM037 to UTF-8 => "été" (.encoding == UTF-8) ``` That way there is no need for those to be Encoding instances, we would only need the conversion tables. It is even better if we can remove them, so the notion of "dummy encodings" can disappear completely and nobody needs to understand or implement them. ### rb_define_dummy_encoding(name) The C-API has `rb_define_dummy_encoding(const char *name)`. This creates a new Encoding instance with `dummy?=true`, and it is also non-ASCII-compatible. There seems to be no purpose to this besides storing the metadata of an encoding which does not exist in Ruby. This seems a really expensive/complex way to handle that from the VM point of view (because it dynamically creates an Encoding and add it to lists/maps/etc). A simple replacement would be to mark the String as BINARY and save the encoding name as an instance variable of that String. Since anyway Ruby can't understand anything about that String, it's just raw bytes to Ruby's eyes. ## Summary I suggest we deprecate replicate and dummy encodings in Ruby 3.2. And then we remove them in the next version. This will significantly simplify string-related methods, and the behavior exposed to Ruby users. It will also significantly speedup encoding lookup in CRuby (and other Ruby implementations). With a fixed number of encodings we can ensure all encoding indices fit in 7 bits, and `ENCODING_GET` can be simply `RB_ENCODING_GET_INLINED`. `get_actual_encoding()` will be gone and its overhead as well. `rb_enc_from_index()` would be just `return global_enc_table->list[index].enc;`, instead of the expensive behavior currently with `GLOBAL_ENC_TABLE_EVAL` which takes a lock and more when there are multiple Ractors. Many checks in these methods would be removed as well. Yet another improvement would be to load all encodings eagerly, that is small and fast in my experience, what is slow and big is the conversion tables, that'd simplify `must_encindex()` further. These changes would affect most String methods, which use ``` STR_ENC_GET->get_encoding which does: get_actual_encoding->rb_enc_from_index and possibly ->enc_from_index ENCODING_GET->RB_ENCODING_GET_INLINED and possibly ->rb_enc_get_index->enc_get_index_str->rb_attr_get ``` Some of these details are mentioned in https://github.com/ruby/ruby/pull/6095#discussion_r915149708. The overhead is so large that it is worth handling some hardcoded encoding indices directly in String methods. This feels wrong, getting the encoding from a String should be simple, straightforward and fast. Further optimizations will be unlocked as the encoding list becomes fixed and immutable. For example, the name-to-Encoding map is then immutable and could use perfect hashing. Inline caching those lookups also becomes easier as the the map cannot change. Also that map would no longer need synchronization, etc. ## To Decide Each item is independent. I think 1 & 2 are very important, 3 less but would be nice. 1. Deprecate and then remove `Encoding#replicate` and `rb_define_dummy_encoding()`. With that there is a fixed number of encodings, a lot of simplifications and many optimizations become available. They are used respectively in only 1 gem and 5 gems, see https://bugs.ruby-lang.org/issues/18949#note-4 2. Deprecate and then remove the dummy UTF-16 and UTF-32 encodings. This removes the need for `get_actual_encoding()` which is expensive. This functionality seems rarely used in practice, and it only works when such strings have a BOM, which is very rare. 3. Deprecate and then remove other dummy encodings, so there are no more dummy "half-implemented" encodings and all encodings are ASCII-compatible in terms of codepoints. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111688] [Ruby master Bug#13671] Regexp with lookbehind and case-insensitivity raises RegexpError only on strings with certain characters
by Eregon (Benoit Daloze) 06 Jan '23

06 Jan '23

Issue #13671 has been updated by Eregon (Benoit Daloze). @duerst Could you take a look at this? It's not fixed yet in 3.2.0. ---------------------------------------- Bug #13671: Regexp with lookbehind and case-insensitivity raises RegexpError only on strings with certain characters https://bugs.ruby-lang.org/issues/13671#change-101088 * Author: dschweisguth (Dave Schweisguth) * Status: Assigned * Priority: Normal * Assignee: duerst (Martin Dürst) * ruby -v: 2.4.1 * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- Here is a test program: ~~~ ruby def test(description) begin yield puts "#{description} is OK" rescue RegexpError puts "#{description} raises RegexpError" end end test("ass, case-insensitive, special") { /(?<!ass)/i =~ '✨' } test("bss, case-insensitive, special") { /(?<!bss)/i =~ '✨' } test("as, case-insensitive, special") { /(?<!as)/i =~ '✨' } test("ss, case-insensitive, special") { /(?<!ss)/i =~ '✨' } test("ass, case-sensitive, special") { /(?<!ass)/ =~ '✨' } test("ass, case-insensitive, regular") { /(?<!ass)/i =~ 'x' } ~~~ Running the test program with Ruby 2.4.1 (macOS) gives ~~~ ass, case-insensitive, special raises RegexpError bss, case-insensitive, special raises RegexpError as, case-insensitive, special is OK ss, case-insensitive, special is OK ass, case-sensitive, special is OK ass, case-insensitive, regular is OK ~~~ The RegexpError is "invalid pattern in look-behind: /(?<!ass)/i (RegexpError)" Side note: in the real code in which I found this error I was able to work around the error by using (?i) after the lookbehind instead of //i. Running the test program with Ruby 2.3.4 does not report any RegexpErrors. I think this is a regression, although I might be wrong and it might be saving me from an incorrect result with certain strings. ---Files-------------------------------- test.rb (531 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111687] [Ruby master Bug#8973] Allow to configure archlibdir for multiarch
by vo.x (Vit Ondruch) 06 Jan '23

06 Jan '23

Issue #8973 has been updated by vo.x (Vit Ondruch). nobu (Nobuyoshi Nakada) wrote in #note-9: > @vo.x With your patch and `--with-multiarch --with-archlibdir='${libdir}'`, not only libruby.so but also all standard library extensions are placed under `${libdir}` without `${arch}`. > Is this intentional? On Fedora, we don't use the `${arch}` anywhere. It is not assumed that we will mix e.g. aarch64 with x86_64 on one filesystem. We only mix 32/64 bit systems, i.e. i686 together with x86_64. But in that case, the 32 bit code is stored in /usr/lib while the 64 bit code is in /usr/lib64. Strictly speaking, we still have troubles with headers, but we are using small platform independent wrapper for them. And the `${arch}` could be useful for some user installed gems, but that is different topic. ---------------------------------------- Bug #8973: Allow to configure archlibdir for multiarch https://bugs.ruby-lang.org/issues/8973#change-101087 * Author: vo.x (Vit Ondruch) * Status: Feedback * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 2.1.0dev (2013-09-22 trunk 43011) [x86_64-linux] ---------------------------------------- Since r39347, there is impossible to configure placement of rubylib.so when build is configured with "--with-multiarch". That is probably OK for Debian, but it breaks Fedora :/ The attached patch allows to configure the archlibdir, but I feel that it is suboptimal, since the "--with-rubyarchprefix" should probably be the parameter which influences placement of the arch specific libraries. Any chance that this patch is accepted or better if rubyarchprefix is respected for every arch specific library, including libruby.so. Thanks. ---Files-------------------------------- ruby-2.1.0-Enable-configuration-of-archlibdir.patch (479 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111686] [Ruby master Feature#18598] Add String#bytesplice
by Eregon (Benoit Daloze) 06 Jan '23

06 Jan '23

Issue #18598 has been updated by Eregon (Benoit Daloze). shugo (Shugo Maeda) wrote in #note-4: > > * Do not use String and e.g. use an Array of byte values or a C extension > > I wouldn't like to implement regular expressions on Array. > > > * Use Ropes or similar implemented in Ruby, which would avoid extra copying and might not need to use byte offsets at all > > I prefer String for the reasons stated above. The typical approach is to flatten (or convert) the Rope to String before matching (whether the Rope is in Ruby or from the VM). I think that is good enough for a text editor. ---------------------------------------- Feature #18598: Add String#bytesplice https://bugs.ruby-lang.org/issues/18598#change-101085 * Author: shugo (Shugo Maeda) * Status: Closed * Priority: Normal ---------------------------------------- I withdrew the proposal of String#bytesplice in #13110 because it may cause problems if the specified offset does not land on character boundary. But how about to raise IndexError in such cases? ``` # encoding: utf-8 s = "あいうえおかきくけこ" s.bytesplice(9, 6, "xx") p s #=> "あいうxxかきくけこ" s.bytesplice(2, 3, "x") #=> offset 2 does not land on character boundary (IndexError) s.bytesplice(3, 4, "x") #=> offset 7 does not land on character boundary (IndexError) ``` ## Pull request https://github.com/ruby/ruby/pull/5584 ## Spec ``` bytesplice(index, length, str) -> string bytesplice(range, str) -> string ``` Replaces some or all of the content of +self+ with +str+, and returns +str+. The portion of the string affected is determined using the same criteria as String#byteslice, except that +length+ cannot be omitted. If the replacement string is not the same length as the text it is replacing, the string will be adjusted accordingly. The form that take an Integer will raise an IndexError if the value is out of range; the Range form will raise a RangeError. If the beginning or ending offset does not land on character (codepoint) boundary, an IndexError will be raised. ## Motivation On a text editor [Textbringer](https://github.com/shugo/textbringer/pull/31/files), the content of a buffer is represented by a String whose encoding is ASCII-8BIT, and `force_encoding(Encoding::UTF_8)` is called when necessary. It's because point (cursor position) and marks are represented by byte offsets for performance, and currently there is no way to modify UTF-8 strings with byte offsets. If String#bytesplice is introduced, the content of a text buffer can be represented by a UTF-8 string, and force_encoding can be removed: https://github.com/shugo/textbringer/pull/31/files -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111658] [Ruby master Bug#19312] SEGV during test_ast.rb: <internal:ast>:76: [BUG] parser_token2id: unknown token -1
by Eregon (Benoit Daloze) 06 Jan '23

06 Jan '23

Issue #19312 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19312: SEGV during test_ast.rb: <internal:ast>:76: [BUG] parser_token2id: unknown token -1 https://bugs.ruby-lang.org/issues/19312 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-01-05T14:24:32Z old 358f325bf8) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` $ make test-all TESTOPTS="test/ruby/test_ast.rb" ... # Running tests: <internal:ast>:76: [BUG] parser_token2id: unknown token -1 ruby 3.3.0dev (2023-01-05T14:24:32Z old 358f325bf8) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0015 p:0003 s:0107 e:000106 METHOD <internal:ast>:76 c:0014 p:0022 s:0098 e:000097 BLOCK /home/eregon/code/ruby/test/ruby/test_ast.rb:137 [FINISH] c:0013 p:0037 s:0091 e:000090 METHOD /home/eregon/code/ruby/tool/lib/test/unit/testcase.rb:200 c:0012 p:0052 s:0085 e:000084 METHOD /home/eregon/code/ruby/tool/lib/test/unit/testcase.rb:168 c:0011 p:0075 s:0076 e:000075 BLOCK /home/eregon/code/ruby/tool/lib/test/unit.rb:1584 [FINISH] c:0010 p:---- s:0069 e:000068 CFUNC :map c:0009 p:0103 s:0065 e:000064 METHOD /home/eregon/code/ruby/tool/lib/test/unit.rb:1571 c:0008 p:0035 s:0053 e:000052 METHOD /home/eregon/code/ruby/tool/lib/test/unit.rb:1364 c:0007 p:0066 s:0046 E:002680 METHOD /home/eregon/code/ruby/tool/lib/test/unit/parallel.rb:58 c:0006 p:0007 s:0030 e:000029 BLOCK /home/eregon/code/ruby/tool/lib/test/unit/parallel.rb:30 [FINISH] c:0005 p:---- s:0026 e:000025 CFUNC :map c:0004 p:0005 s:0022 e:000021 METHOD /home/eregon/code/ruby/tool/lib/test/unit/parallel.rb:29 c:0003 p:0202 s:0016 e:000015 METHOD /home/eregon/code/ruby/tool/lib/test/unit/parallel.rb:128 c:0002 p:0098 s:0006 e:000005 EVAL /home/eregon/code/ruby/tool/lib/test/unit/parallel.rb:211 [FINISH] c:0001 p:0000 s:0003 E:000260 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /home/eregon/code/ruby/tool/lib/test/unit/parallel.rb:211:in `<main>' /home/eregon/code/ruby/tool/lib/test/unit/parallel.rb:128:in `run' /home/eregon/code/ruby/tool/lib/test/unit/parallel.rb:29:in `_run_suites' /home/eregon/code/ruby/tool/lib/test/unit/parallel.rb:29:in `map' /home/eregon/code/ruby/tool/lib/test/unit/parallel.rb:30:in `block in _run_suites' /home/eregon/code/ruby/tool/lib/test/unit/parallel.rb:58:in `_run_suite' /home/eregon/code/ruby/tool/lib/test/unit.rb:1364:in `_run_suite' /home/eregon/code/ruby/tool/lib/test/unit.rb:1571:in `_run_suite' /home/eregon/code/ruby/tool/lib/test/unit.rb:1571:in `map' /home/eregon/code/ruby/tool/lib/test/unit.rb:1584:in `block in _run_suite' /home/eregon/code/ruby/tool/lib/test/unit/testcase.rb:168:in `run' /home/eregon/code/ruby/tool/lib/test/unit/testcase.rb:200:in `run_test' /home/eregon/code/ruby/test/ruby/test_ast.rb:137:in `block (2 levels) in <class:TestAst>' <internal:ast>:76:in `parse_file' -- C level backtrace information ------------------------------------------- /home/eregon/code/ruby/ruby(rb_print_backtrace+0xd) [0x5620d00cba91] /home/eregon/code/ruby/vm_dump.c:785 /home/eregon/code/ruby/ruby(rb_vm_bugreport) /home/eregon/code/ruby/vm_dump.c:1080 /home/eregon/code/ruby/ruby(bug_report_end+0x0) [0x5620d0258dbb] /home/eregon/code/ruby/error.c:790 /home/eregon/code/ruby/ruby(rb_bug_without_die) /home/eregon/code/ruby/error.c:790 /home/eregon/code/ruby/ruby(die+0x0) [0x5620cfeb2cc8] /home/eregon/code/ruby/error.c:798 /home/eregon/code/ruby/ruby(rb_bug) /home/eregon/code/ruby/error.c:800 /home/eregon/code/ruby/ruby(rb_long2int_inline+0x0) [0x5620cfeaa427] /home/eregon/code/ruby/parse.y:630 /home/eregon/code/ruby/ruby(add_delayed_token) /home/eregon/code/ruby/parse.y:7022 /home/eregon/code/ruby/ruby(add_delayed_token) /home/eregon/code/ruby/parse.y:7011 /home/eregon/code/ruby/ruby(parser_dispatch_scan_event+0x5d) [0x5620cff8810b] /home/eregon/code/ruby/parse.y:6236 /home/eregon/code/ruby/ruby(parser_dispatch_scan_event) /home/eregon/code/ruby/parse.y:6226 /home/eregon/code/ruby/ruby(yylex+0xf) [0x5620cff97996] /home/eregon/code/ruby/parse.y:10508 /home/eregon/code/ruby/ruby(ruby_yyparse) /home/eregon/code/ruby/parse.c:9308 /home/eregon/code/ruby/ruby(yycompile0+0xf5) [0x5620cffa98b5] /home/eregon/code/ruby/parse.y:6781 /home/eregon/code/ruby/ruby(rb_suppress_tracing+0xf9) [0x5620d00d0d19] /home/eregon/code/ruby/vm_trace.c:465 /home/eregon/code/ruby/ruby(yycompile+0x58) [0x5620cff9588a] /home/eregon/code/ruby/parse.y:6838 /home/eregon/code/ruby/ruby(rb_parser_compile_file_path) /home/eregon/code/ruby/parse.y:6941 /home/eregon/code/ruby/ruby(rb_ast_parse_file+0x116) [0x5620d01d7646] /home/eregon/code/ruby/ast.c:127 /home/eregon/code/ruby/ruby(invoke_bf+0x13) [0x5620d00bd26e] /home/eregon/code/ruby/vm_insnhelper.c:6286 /home/eregon/code/ruby/ruby(vm_invoke_builtin_delegate) /home/eregon/code/ruby/vm_insnhelper.c:6313 /home/eregon/code/ruby/ruby(vm_exec_core) /home/eregon/code/ruby/insns.def:1512 /home/eregon/code/ruby/ruby(rb_vm_exec+0xb3) [0x5620d00ae933] /home/eregon/code/ruby/vm.c:2374 /home/eregon/code/ruby/ruby(vm_call_bmethod+0xd2) [0x5620d00affd2] /home/eregon/code/ruby/vm_insnhelper.c:3344 /home/eregon/code/ruby/ruby(vm_call_symbol+0x2a1) [0x5620d00b1691] /home/eregon/code/ruby/vm_insnhelper.c:3506 /home/eregon/code/ruby/ruby(vm_sendish+0xa4) [0x5620d00bcf35] /home/eregon/code/ruby/vm_insnhelper.c:5064 /home/eregon/code/ruby/ruby(vm_exec_core) /home/eregon/code/ruby/insns.def:820 /home/eregon/code/ruby/ruby(rb_vm_exec+0xb3) [0x5620d00ae933] /home/eregon/code/ruby/vm.c:2374 /home/eregon/code/ruby/ruby(rb_yield+0x1ce) [0x5620d00c340e] /home/eregon/code/ruby/vm.c:1398 /home/eregon/code/ruby/ruby(RB_FL_TEST_RAW+0x0) [0x5620d01cceb6] /home/eregon/code/ruby/array.c:3834 /home/eregon/code/ruby/ruby(RB_FL_ANY_RAW) ./include/ruby/internal/fl_type.h:552 /home/eregon/code/ruby/ruby(rb_array_len) ./include/ruby/internal/core/rarray.h:321 /home/eregon/code/ruby/ruby(rb_ary_push) /home/eregon/code/ruby/array.c:1485 /home/eregon/code/ruby/ruby(rb_ary_collect) /home/eregon/code/ruby/array.c:3834 /home/eregon/code/ruby/ruby(vm_call_cfunc_with_frame+0x117) [0x5620d00a2217] /home/eregon/code/ruby/vm_insnhelper.c:3252 /home/eregon/code/ruby/ruby(vm_sendish+0xfb) [0x5620d00a6bfb] /home/eregon/code/ruby/vm_insnhelper.c:5064 /home/eregon/code/ruby/ruby(vm_exec_core+0x1538) [0x5620d00be368] /home/eregon/code/ruby/insns.def:801 /home/eregon/code/ruby/ruby(rb_vm_exec+0xb3) [0x5620d00ae933] /home/eregon/code/ruby/vm.c:2374 /home/eregon/code/ruby/ruby(rb_yield+0x1ce) [0x5620d00c340e] /home/eregon/code/ruby/vm.c:1398 /home/eregon/code/ruby/ruby(RB_FL_TEST_RAW+0x0) [0x5620d01cceb6] /home/eregon/code/ruby/array.c:3834 /home/eregon/code/ruby/ruby(RB_FL_ANY_RAW) ./include/ruby/internal/fl_type.h:552 /home/eregon/code/ruby/ruby(rb_array_len) ./include/ruby/internal/core/rarray.h:321 /home/eregon/code/ruby/ruby(rb_ary_push) /home/eregon/code/ruby/array.c:1485 /home/eregon/code/ruby/ruby(rb_ary_collect) /home/eregon/code/ruby/array.c:3834 /home/eregon/code/ruby/ruby(vm_call_cfunc_with_frame+0x117) [0x5620d00a2217] /home/eregon/code/ruby/vm_insnhelper.c:3252 /home/eregon/code/ruby/ruby(vm_sendish+0xfb) [0x5620d00a6bfb] /home/eregon/code/ruby/vm_insnhelper.c:5064 /home/eregon/code/ruby/ruby(vm_exec_core+0x1538) [0x5620d00be368] /home/eregon/code/ruby/insns.def:801 /home/eregon/code/ruby/ruby(rb_vm_exec+0x55c) [0x5620d00aeddc] /home/eregon/code/ruby/vm.c:2383 /home/eregon/code/ruby/ruby(rb_ec_exec_node+0xa5) [0x5620cfeb4005] /home/eregon/code/ruby/eval.c:289 /home/eregon/code/ruby/ruby(ruby_run_node+0x48) [0x5620cfeb91f8] /home/eregon/code/ruby/eval.c:330 /home/eregon/code/ruby/ruby(rb_main+0x21) [0x5620cfeb3c92] capstone/arch/AArch64/AArch64BaseInfo.h:232 /home/eregon/code/ruby/ruby(main) ./main.c:57 /lib64/libc.so.6(__libc_start_call_main+0x80) [0x7f2b5efb1510] /lib64/libc.so.6(__libc_start_main+0x89) [0x7f2b5efb15c9] [0x5620cfeb3cd5] -- Other runtime information ----------------------------------------------- * Loaded script: /home/eregon/code/ruby/tool/lib/test/unit/parallel.rb: TestAst#test_all_tokens:test/fiber/queue.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 ruby2_keywords.rb 6 /home/eregon/code/ruby/.ext/x86_64-linux/enc/encdb.so 7 /home/eregon/code/ruby/.ext/x86_64-linux/enc/trans/transdb.so 8 /home/eregon/code/ruby/lib/open3/version.rb 9 /home/eregon/code/ruby/lib/open3.rb 10 /home/eregon/code/ruby/lib/timeout.rb 11 /home/eregon/code/ruby/rbconfig.rb 12 /home/eregon/code/ruby/tool/lib/find_executable.rb 13 /home/eregon/code/ruby/.ext/x86_64-linux/rbconfig/sizeof.so 14 /home/eregon/code/ruby/tool/lib/envutil.rb 15 /home/eregon/code/ruby/tool/lib/colorize.rb 16 /home/eregon/code/ruby/tool/lib/leakchecker.rb 17 /home/eregon/code/ruby/lib/prettyprint.rb 18 /home/eregon/code/ruby/lib/pp.rb 19 /home/eregon/code/ruby/tool/lib/test/unit/assertions.rb 20 /home/eregon/code/ruby/.ext/x86_64-linux/io/console.so 21 /home/eregon/code/ruby/tool/lib/core_assertions.rb 22 /home/eregon/code/ruby/tool/lib/test/unit/testcase.rb 23 /home/eregon/code/ruby/lib/optparse.rb 24 /home/eregon/code/ruby/tool/lib/test/unit.rb 25 /home/eregon/code/ruby/tool/lib/tracepointchecker.rb 26 /home/eregon/code/ruby/tool/lib/zombie_hunter.rb 27 /home/eregon/code/ruby/lib/delegate.rb 28 /home/eregon/code/ruby/lib/fileutils.rb 29 /home/eregon/code/ruby/.ext/x86_64-linux/etc.so 30 /home/eregon/code/ruby/lib/tmpdir.rb 31 /home/eregon/code/ruby/lib/tempfile.rb 32 /home/eregon/code/ruby/tool/lib/iseq_loader_checker.rb 33 /home/eregon/code/ruby/tool/lib/gc_checker.rb 34 /home/eregon/code/ruby/lib/rubygems/compatibility.rb 35 /home/eregon/code/ruby/lib/rubygems/defaults.rb 36 /home/eregon/code/ruby/lib/rubygems/deprecate.rb 37 /home/eregon/code/ruby/lib/rubygems/errors.rb 38 /home/eregon/code/ruby/lib/rubygems/unknown_command_spell_checker.rb 39 /home/eregon/code/ruby/lib/rubygems/exceptions.rb 40 /home/eregon/code/ruby/lib/rubygems/basic_specification.rb 41 /home/eregon/code/ruby/lib/rubygems/stub_specification.rb 42 /home/eregon/code/ruby/lib/rubygems/platform.rb 43 /home/eregon/code/ruby/lib/rubygems/util/list.rb 44 /home/eregon/code/ruby/lib/rubygems/version.rb 45 /home/eregon/code/ruby/lib/rubygems/requirement.rb 46 /home/eregon/code/ruby/lib/rubygems/specification.rb 47 /home/eregon/code/ruby/lib/rubygems/util.rb 48 /home/eregon/code/ruby/lib/rubygems/dependency.rb 49 /home/eregon/code/ruby/lib/rubygems/core_ext/kernel_gem.rb 50 /home/eregon/code/ruby/.ext/x86_64-linux/monitor.so 51 /home/eregon/code/ruby/.ext/common/monitor.rb 52 /home/eregon/code/ruby/lib/rubygems/core_ext/kernel_require.rb 53 /home/eregon/code/ruby/lib/rubygems/core_ext/kernel_warn.rb 54 /home/eregon/code/ruby/lib/rubygems.rb 55 /home/eregon/code/ruby/test/ruby/test_ast.rb * Process memory map: 5620cfc0d000-5620cfea8000 r--p 00000000 fd:00 30807089 /home/eregon/code/ruby/ruby 5620cfea8000-5620d03e2000 r-xp 0029b000 fd:00 30807089 /home/eregon/code/ruby/ruby 5620d03e2000-5620d09d2000 r--p 007d5000 fd:00 30807089 /home/eregon/code/ruby/ruby 5620d09d2000-5620d0b24000 r--p 00dc4000 fd:00 30807089 /home/eregon/code/ruby/ruby 5620d0b24000-5620d0b25000 rw-p 00f16000 fd:00 30807089 /home/eregon/code/ruby/ruby 5620d0b25000-5620d0b39000 rw-p 00000000 00:00 0 5620d1541000-5620d1ec7000 rw-p 00000000 00:00 0 [heap] 7f2b44400000-7f2b47ea5000 r--s 00000000 fd:00 30807089 /home/eregon/code/ruby/ruby 7f2b48000000-7f2b48021000 rw-p 00000000 00:00 0 7f2b48021000-7f2b4c000000 ---p 00000000 00:00 0 7f2b4d200000-7f2b4d420000 r--s 00000000 fd:00 13388284 /usr/lib64/libc.so.6 7f2b4d540000-7f2b4d560000 rw-p 00000000 00:00 0 7f2b4d570000-7f2b4d5f0000 rw-p 00000000 00:00 0 7f2b4d650000-7f2b4d6c0000 rw-p 00000000 00:00 0 7f2b4d6d0000-7f2b4d700000 rw-p 00000000 00:00 0 7f2b4d70f000-7f2b4d7f0000 rw-p 00000000 00:00 0 7f2b4d800000-7f2b4d860000 rw-p 00000000 00:00 0 7f2b4d870000-7f2b4da70000 rw-p 00000000 00:00 0 7f2b4da7f000-7f2b4db00000 rw-p 00000000 00:00 0 7f2b4db10000-7f2b4dbf0000 rw-p 00000000 00:00 0 7f2b4dbff000-7f2b4dc00000 ---p 00000000 00:00 0 7f2b4dc00000-7f2b4de30000 rw-p 00000000 00:00 0 7f2b4de37000-7f2b4de39000 r--p 00000000 fd:00 31467068 /home/eregon/code/ruby/.ext/x86_64-linux/etc.so 7f2b4de39000-7f2b4de3c000 r-xp 00002000 fd:00 31467068 /home/eregon/code/ruby/.ext/x86_64-linux/etc.so 7f2b4de3c000-7f2b4de3e000 r--p 00005000 fd:00 31467068 /home/eregon/code/ruby/.ext/x86_64-linux/etc.so 7f2b4de3e000-7f2b4de3f000 r--p 00006000 fd:00 31467068 /home/eregon/code/ruby/.ext/x86_64-linux/etc.so 7f2b4de3f000-7f2b4de40000 rw-p 00007000 fd:00 31467068 /home/eregon/code/ruby/.ext/x86_64-linux/etc.so 7f2b4de40000-7f2b4df30000 rw-p 00000000 00:00 0 7f2b4df35000-7f2b4df37000 r--p 00000000 fd:00 31467115 /home/eregon/code/ruby/.ext/x86_64-linux/io/console.so 7f2b4df37000-7f2b4df3c000 r-xp 00002000 fd:00 31467115 /home/eregon/code/ruby/.ext/x86_64-linux/io/console.so 7f2b4df3c000-7f2b4df3d000 r--p 00007000 fd:00 31467115 /home/eregon/code/ruby/.ext/x86_64-linux/io/console.so 7f2b4df3d000-7f2b4df3e000 ---p 00008000 fd:00 31467115 /home/eregon/code/ruby/.ext/x86_64-linux/io/console.so 7f2b4df3e000-7f2b4df3f000 r--p 00008000 fd:00 31467115 /home/eregon/code/ruby/.ext/x86_64-linux/io/console.so 7f2b4df3f000-7f2b4df40000 rw-p 00009000 fd:00 31467115 /home/eregon/code/ruby/.ext/x86_64-linux/io/console.so 7f2b4df40000-7f2b4df80000 rw-p 00000000 00:00 0 7f2b4df80000-7f2b4df81000 ---p 00000000 00:00 0 7f2b4df81000-7f2b4dfc2000 rw-p 00000000 00:00 0 7f2b4dfc2000-7f2b4dfc3000 ---p 00000000 00:00 0 7f2b4dfc3000-7f2b4e004000 rw-p 00000000 00:00 0 7f2b4e004000-7f2b4e005000 ---p 00000000 00:00 0 7f2b4e005000-7f2b4e046000 rw-p 00000000 00:00 0 7f2b4e046000-7f2b4e047000 ---p 00000000 00:00 0 7f2b4e047000-7f2b4e088000 rw-p 00000000 00:00 0 7f2b4e088000-7f2b4e089000 ---p 00000000 00:00 0 7f2b4e089000-7f2b4e0ca000 rw-p 00000000 00:00 0 7f2b4e0ca000-7f2b4e0cb000 ---p 00000000 00:00 0 7f2b4e0cb000-7f2b4e10c000 rw-p 00000000 00:00 0 7f2b4e10c000-7f2b4e10d000 ---p 00000000 00:00 0 7f2b4e10d000-7f2b4e14e000 rw-p 00000000 00:00 0 7f2b4e14e000-7f2b4e14f000 ---p 00000000 00:00 0 7f2b4e14f000-7f2b4e190000 rw-p 00000000 00:00 0 7f2b4e190000-7f2b4e191000 ---p 00000000 00:00 0 7f2b4e191000-7f2b4e1d2000 rw-p 00000000 00:00 0 7f2b4e1d2000-7f2b4e1d3000 ---p 00000000 00:00 0 7f2b4e1d3000-7f2b4e214000 rw-p 00000000 00:00 0 7f2b4e214000-7f2b4e215000 ---p 00000000 00:00 0 7f2b4e215000-7f2b4e256000 rw-p 00000000 00:00 0 7f2b4e256000-7f2b4e257000 ---p 00000000 00:00 0 7f2b4e257000-7f2b4e298000 rw-p 00000000 00:00 0 7f2b4e298000-7f2b4e299000 ---p 00000000 00:00 0 7f2b4e299000-7f2b4e2da000 rw-p 00000000 00:00 0 7f2b4e2da000-7f2b4e2db000 ---p 00000000 00:00 0 7f2b4e2db000-7f2b4e31c000 rw-p 00000000 00:00 0 7f2b4e31c000-7f2b4e31d000 ---p 00000000 00:00 0 7f2b4e31d000-7f2b4e35e000 rw-p 00000000 00:00 0 7f2b4e35e000-7f2b4e35f000 ---p 00000000 00:00 0 7f2b4e35f000-7f2b4e3a0000 rw-p 00000000 00:00 0 7f2b4e3a0000-7f2b4e3a1000 ---p 00000000 00:00 0 7f2b4e3a1000-7f2b4e3e2000 rw-p 00000000 00:00 0 7f2b4e3e2000-7f2b4e3e3000 ---p 00000000 00:00 0 7f2b4e3e3000-7f2b4e424000 rw-p 00000000 00:00 0 7f2b4e424000-7f2b4e425000 ---p 00000000 00:00 0 7f2b4e425000-7f2b4e466000 rw-p 00000000 00:00 0 7f2b4e466000-7f2b4e467000 ---p 00000000 00:00 0 7f2b4e467000-7f2b4e4a8000 rw-p 00000000 00:00 0 7f2b4e4a8000-7f2b4e4a9000 ---p 00000000 00:00 0 7f2b4e4a9000-7f2b4e4ea000 rw-p 00000000 00:00 0 7f2b4e4ea000-7f2b4e4eb000 ---p 00000000 00:00 0 7f2b4e4eb000-7f2b4e52c000 rw-p 00000000 00:00 0 7f2b4e52c000-7f2b4e52d000 ---p 00000000 00:00 0 7f2b4e52d000-7f2b4e56e000 rw-p 00000000 00:00 0 7f2b4e56e000-7f2b4e56f000 ---p 00000000 00:00 0 7f2b4e56f000-7f2b4e5b0000 rw-p 00000000 00:00 0 7f2b4e5b0000-7f2b4e5b1000 ---p 00000000 00:00 0 7f2b4e5b1000-7f2b4e5f2000 rw-p 00000000 00:00 0 7f2b4e5f2000-7f2b4e5f3000 ---p 00000000 00:00 0 7f2b4e5f3000-7f2b4e634000 rw-p 00000000 00:00 0 7f2b4e634000-7f2b4e635000 ---p 00000000 00:00 0 7f2b4e635000-7f2b4e676000 rw-p 00000000 00:00 0 7f2b4e676000-7f2b4e677000 ---p 00000000 00:00 0 7f2b4e677000-7f2b4e6b8000 rw-p 00000000 00:00 0 7f2b4e6b8000-7f2b4e6b9000 ---p 00000000 00:00 0 7f2b4e6b9000-7f2b4e6fa000 rw-p 00000000 00:00 0 7f2b4e6fa000-7f2b4e6fb000 ---p 00000000 00:00 0 7f2b4e6fb000-7f2b4e73c000 rw-p 00000000 00:00 0 7f2b4e73c000-7f2b4e73d000 ---p 00000000 00:00 0 7f2b4e73d000-7f2b4e77e000 rw-p 00000000 00:00 0 7f2b4e77e000-7f2b4e77f000 ---p 00000000 00:00 0 7f2b4e77f000-7f2b4e7f0000 rw-p 00000000 00:00 0 7f2b4e7f7000-7f2b51800000 rw-p 00000000 00:00 0 7f2b51800000-7f2b5edb9000 r--p 00000000 fd:00 13369444 /usr/lib/locale/locale-archive 7f2b5edba000-7f2b5edbb000 r--p 00000000 fd:00 31467118 /home/eregon/code/ruby/.ext/x86_64-linux/monitor.so 7f2b5edbb000-7f2b5edbc000 r-xp 00001000 fd:00 31467118 /home/eregon/code/ruby/.ext/x86_64-linux/monitor.so 7f2b5edbc000-7f2b5edbd000 r--p 00002000 fd:00 31467118 /home/eregon/code/ruby/.ext/x86_64-linux/monitor.so 7f2b5edbd000-7f2b5edbe000 r--p 00002000 fd:00 31467118 /home/eregon/code/ruby/.ext/x86_64-linux/monitor.so 7f2b5edbe000-7f2b5edbf000 rw-p 00003000 fd:00 31467118 /home/eregon/code/ruby/.ext/x86_64-linux/monitor.so 7f2b5edd0000-7f2b5ee80000 rw-p 00000000 00:00 0 7f2b5ee84000-7f2b5ef8a000 rw-p 00000000 00:00 0 7f2b5ef8a000-7f2b5efb0000 r--p 00000000 fd:00 13388284 /usr/lib64/libc.so.6 7f2b5efb0000-7f2b5f106000 r-xp 00026000 fd:00 13388284 /usr/lib64/libc.so.6 7f2b5f106000-7f2b5f159000 r--p 0017c000 fd:00 13388284 /usr/lib64/libc.so.6 7f2b5f159000-7f2b5f15d000 r--p 001ce000 fd:00 13388284 /usr/lib64/libc.so.6 7f2b5f15d000-7f2b5f15f000 rw-p 001d2000 fd:00 13388284 /usr/lib64/libc.so.6 7f2b5f15f000-7f2b5f167000 rw-p 00000000 00:00 0 7f2b5f167000-7f2b5f16a000 r--p 00000000 fd:00 13369381 /usr/lib64/libgcc_s-12-20221121.so.1 7f2b5f16a000-7f2b5f181000 r-xp 00003000 fd:00 13369381 /usr/lib64/libgcc_s-12-20221121.so.1 7f2b5f181000-7f2b5f185000 r--p 0001a000 fd:00 13369381 /usr/lib64/libgcc_s-12-20221121.so.1 7f2b5f185000-7f2b5f186000 r--p 0001d000 fd:00 13369381 /usr/lib64/libgcc_s-12-20221121.so.1 7f2b5f186000-7f2b5f187000 rw-p 00000000 00:00 0 7f2b5f187000-7f2b5f197000 r--p 00000000 fd:00 13388287 /usr/lib64/libm.so.6 7f2b5f197000-7f2b5f20b000 r-xp 00010000 fd:00 13388287 /usr/lib64/libm.so.6 7f2b5f20b000-7f2b5f265000 r--p 00084000 fd:00 13388287 /usr/lib64/libm.so.6 7f2b5f265000-7f2b5f266000 r--p 000dd000 fd:00 13388287 /usr/lib64/libm.so.6 7f2b5f266000-7f2b5f267000 rw-p 000de000 fd:00 13388287 /usr/lib64/libm.so.6 7f2b5f267000-7f2b5f269000 r--p 00000000 fd:00 13389453 /usr/lib64/libcrypt.so.2.0.0 7f2b5f269000-7f2b5f27d000 r-xp 00002000 fd:00 13389453 /usr/lib64/libcrypt.so.2.0.0 7f2b5f27d000-7f2b5f297000 r--p 00016000 fd:00 13389453 /usr/lib64/libcrypt.so.2.0.0 7f2b5f297000-7f2b5f298000 r--p 0002f000 fd:00 13389453 /usr/lib64/libcrypt.so.2.0.0 7f2b5f298000-7f2b5f2a1000 rw-p 00000000 00:00 0 7f2b5f2a1000-7f2b5f2a4000 r--p 00000000 fd:00 13388614 /usr/lib64/libz.so.1.2.12 7f2b5f2a4000-7f2b5f2b2000 r-xp 00003000 fd:00 13388614 /usr/lib64/libz.so.1.2.12 7f2b5f2b2000-7f2b5f2b9000 r--p 00011000 fd:00 13388614 /usr/lib64/libz.so.1.2.12 7f2b5f2b9000-7f2b5f2ba000 r--p 00017000 fd:00 13388614 /usr/lib64/libz.so.1.2.12 7f2b5f2ba000-7f2b5f2bb000 rw-p 00000000 00:00 0 7f2b5f2bd000-7f2b5f2be000 r--p 00000000 fd:00 31467181 /home/eregon/code/ruby/.ext/x86_64-linux/rbconfig/sizeof.so 7f2b5f2be000-7f2b5f2c0000 r-xp 00001000 fd:00 31467181 /home/eregon/code/ruby/.ext/x86_64-linux/rbconfig/sizeof.so 7f2b5f2c0000-7f2b5f2c1000 r--p 00003000 fd:00 31467181 /home/eregon/code/ruby/.ext/x86_64-linux/rbconfig/sizeof.so 7f2b5f2c1000-7f2b5f2c2000 r--p 00003000 fd:00 31467181 /home/eregon/code/ruby/.ext/x86_64-linux/rbconfig/sizeof.so 7f2b5f2c2000-7f2b5f2c3000 rw-p 00004000 fd:00 31467181 /home/eregon/code/ruby/.ext/x86_64-linux/rbconfig/sizeof.so 7f2b5f2c3000-7f2b5f2c4000 r--p 00000000 fd:00 31466889 /home/eregon/code/ruby/.ext/x86_64-linux/enc/trans/transdb.so 7f2b5f2c4000-7f2b5f2c5000 r-xp 00001000 fd:00 31466889 /home/eregon/code/ruby/.ext/x86_64-linux/enc/trans/transdb.so 7f2b5f2c5000-7f2b5f2c6000 r--p 00002000 fd:00 31466889 /home/eregon/code/ruby/.ext/x86_64-linux/enc/trans/transdb.so 7f2b5f2c6000-7f2b5f2c7000 r--p 00002000 fd:00 31466889 /home/eregon/code/ruby/.ext/x86_64-linux/enc/trans/transdb.so 7f2b5f2c7000-7f2b5f2c8000 rw-p 00003000 fd:00 31466889 /home/eregon/code/ruby/.ext/x86_64-linux/enc/trans/transdb.so 7f2b5f2c8000-7f2b5f2c9000 r--p 00000000 fd:00 31466919 /home/eregon/code/ruby/.ext/x86_64-linux/enc/encdb.so 7f2b5f2c9000-7f2b5f2ca000 r-xp 00001000 fd:00 31466919 /home/eregon/code/ruby/.ext/x86_64-linux/enc/encdb.so 7f2b5f2ca000-7f2b5f2cb000 r--p 00002000 fd:00 31466919 /home/eregon/code/ruby/.ext/x86_64-linux/enc/encdb.so 7f2b5f2cb000-7f2b5f2cc000 r--p 00002000 fd:00 31466919 /home/eregon/code/ruby/.ext/x86_64-linux/enc/encdb.so 7f2b5f2cc000-7f2b5f2cd000 rw-p 00003000 fd:00 31466919 /home/eregon/code/ruby/.ext/x86_64-linux/enc/encdb.so 7f2b5f2cd000-7f2b5f2d4000 r--s 00000000 fd:00 13893644 /usr/lib64/gconv/gconv-modules.cache 7f2b5f2d4000-7f2b5f2d6000 rw-p 00000000 00:00 0 7f2b5f2d6000-7f2b5f2d7000 r--p 00000000 fd:00 13388281 /usr/lib64/ld-linux-x86-64.so.2 7f2b5f2d7000-7f2b5f2fe000 r-xp 00001000 fd:00 13388281 /usr/lib64/ld-linux-x86-64.so.2 7f2b5f2fe000-7f2b5f308000 r--p 00028000 fd:00 13388281 /usr/lib64/ld-linux-x86-64.so.2 7f2b5f309000-7f2b5f30b000 r--p 00032000 fd:00 13388281 /usr/lib64/ld-linux-x86-64.so.2 7f2b5f30b000-7f2b5f30d000 rw-p 00034000 fd:00 13388281 /usr/lib64/ld-linux-x86-64.so.2 7fff1f6e8000-7fff1fee7000 rw-p 00000000 00:00 0 [stack] 7fff1ffbb000-7fff1ffbf000 r--p 00000000 00:00 0 [vvar] 7fff1ffbf000-7fff1ffc1000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] running file: test/ruby/test_ast.rb A test worker crashed. It might be an interpreter bug or a bug in test/unit/parallel.rb. Try again without the -j option. make: *** [uncommon.mk:855: yes-test-all] Error 1 ``` On Fedora 37 -- https://bugs.ruby-lang.org/

2 2