- ruby-core - ml.ruby-lang.org

[ruby-core:115845] [Ruby master Bug#20078] StringIO cannot be moved between Ractors
by forthoney (Seong-Heon Jung) 11 Jan '24

11 Jan '24

Issue #20078 has been reported by forthoney (Seong-Heon Jung). ---------------------------------------- Bug #20078: StringIO cannot be moved between Ractors https://bugs.ruby-lang.org/issues/20078 * Author: forthoney (Seong-Heon Jung) * Status: Open * Priority: Normal * ruby -v: 3.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following code will raise an unusual Ractor error. ``` ruby require 'stringio' r = Ractor.new { loop { Ractor.receive } } Ractor.shareable?(StringIO.new) #=> false r.send(StringIO.new) # passing it via copy works r.send(StringIO.new, move: true) # <internal:ractor>:587:in `send': can not move StringIO object. (Ractor::Error) ``` I'm not 100% sure but I believe that this probably not the intended behavior considering * The error raised is a generic `Ractor::Error` rather than something specific like Ractor::MovedError or Ractor::IsolationError * It can be copied * [No documentation](https://docs.ruby-lang.org/en/master/ractor_md.html) exists for this error * I have yet to seen this happen on any other class instance * Typo (can not -> cannot) -- https://bugs.ruby-lang.org/

3 6

[ruby-core:116061] [Ruby master Bug#20158] Ractor affects Coverage results
by janosch-x 11 Jan '24

11 Jan '24

Issue #20158 has been reported by janosch-x (Janosch Müller). ---------------------------------------- Bug #20158: Ractor affects Coverage results https://bugs.ruby-lang.org/issues/20158 * Author: janosch-x (Janosch Müller) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0preview1 (2023-05-12 master a1b01e7701) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I have a large rspec test suite. I found that if I call a Ractor, the Coverage results are strongly affected, i.e. almost all files appear to be uncovered. This happens even if I only ever call a Ractor before the library or rspec are required. Unfortunately, I was not able to build a simple repro yet. I assume it is a timing thing and only affects larger suites, or it only happens if there are multiple files, and maybe if the library lazily requires its sub-modules? However, I guess this should produce the same results when added to the spec_helper.rb of other large suites: ```ruby # Ractor.new { nil } # uncomment this to affect coverage results require 'coverage' Coverage.start # require library, set up rspec etc. RSpec.configuration.after(:suite) do # this number is greatly reduced and unstable when calling Ractor above p Coverage.result.values.sum { |arr| arr.sum(&:to_i) } end ``` I had this problem in [this library](https://github.com/jaynetics/character_set/). The problem affects simplecov users as well, as described [here](https://github.com/simplecov-ruby/simplecov/issues/1058). -- https://bugs.ruby-lang.org/

3 4

[ruby-core:116173] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by byroot (Jean Boussier) 11 Jan '24

11 Jan '24

Issue #18576 has been updated by byroot (Jean Boussier). I would also like to try this again for 3.4, if we do it early, the potential remaining issue will have a chance to be noticed with the first preview release. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106186 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116172] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by Eregon (Benoit Daloze) 11 Jan '24

11 Jan '24

Issue #18576 has been updated by Eregon (Benoit Daloze). Also given the efforts of @byroot in https://bugs.ruby-lang.org/issues/18576#note-21 and the offer from @matz in https://bugs.ruby-lang.org/issues/18576#note-19, I'd like to do exactly what matz said: > If you (or someone) estimate the compatibility issue is minimal, and want to experiment to see if it's true during pre-release, I'd say go. I estimate it to be minimal. We can know from the experiment if it's true or not, there are more than 11 months before 3.4, so plenty of time to discover any potential issue with it. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106185 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116170] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by Eregon (Benoit Daloze) 11 Jan '24

11 Jan '24

Issue #18576 has been updated by Eregon (Benoit Daloze). @naruse Do you have evidence of (latest release and not ancient) gems or applications comparing `encoding.name` to `'ASCII-8BIT'`? I think it's so obviously a bad idea to compare the encoding name as a String, AFAIK there was never a valid reason to use it (over `enc == Encoding::BINARY`, which works since Ruby 1.9) and it's inefficient, brittle and unnecessary. FWIW https://github.com/search?q=%22name+%3D%3D+%27ASCII-8BIT%27%22&type=code&p=1 shows very few matches and it's mostly copies of old VCR code. The chance of that code running on Ruby 3.4+ seems almost nonexistent, there would likely be many more serious compatibility issues with such old code (e.g. kwargs changes). And fixing it is really easy. @matz Can we experiment for 3.4? If we have pushback based on actual code then let's go more conservative, but otherwise I think we should do the clean fix here. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106183 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115736] [Ruby master Bug#20064] Inconsistent behavior between array splat *nil and hash splat **nil
by zeke (Zeke Gabrielse) 10 Jan '24

10 Jan '24

Issue #20064 has been reported by zeke (Zeke Gabrielse). ---------------------------------------- Bug #20064: Inconsistent behavior between array splat *nil and hash splat **nil https://bugs.ruby-lang.org/issues/20064 * Author: zeke (Zeke Gabrielse) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This has been discussed in #8507 and #9291 but both were closed because they lacked a clear use case. I think the following code should work, showing a clear use case: ```ruby invitation = if params.key?(:inviter_id) { invitation_attributes: params.slice(:inviter_id) } end User.create( email: 'john.doe(a)ruby.example', first_name: 'John', first_name: 'Doe', **invitation, ) ``` Per the previous discussions, this is because `*` uses explicit conversion to array (`to_a`, not `to_ary`), while `**` uses implicit conversion to hash (`to_hash`, not `to_h`). I find it confusing that you can splat nil into an array, but not nil into a hash. It would make sense for `**` to use explicit conversion. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:116163] [Ruby master Feature#20177] Optimized $LOADED_FEATURES.include?
by palkan (Vladimir Dementyev) 10 Jan '24

10 Jan '24

Issue #20177 has been reported by palkan (Vladimir Dementyev). ---------------------------------------- Feature #20177: Optimized $LOADED_FEATURES.include? https://bugs.ruby-lang.org/issues/20177 * Author: palkan (Vladimir Dementyev) * Status: Open * Priority: Normal ---------------------------------------- I'd like to propose adding the optimized `$LOADED_FEATURES.include?` (not the one provided by the Array class) for faster feature checks in large codebases (when there are thousands of entries in the features list). I hit this problem while working on [require-hooks](https://github.com/ruby-next/require-hooks#results). We can use the internal `vm->loaded_features_realpaths` Hash to achieve faster lookups (it's used by MRI's `require / load` mechanism). Alternatively to overriding the `#include?` method, we can introduce a custom API similar to how `$LOAD_PATH.resolve_feature_path` has been introduced (e.g., `$LOADED_FEATURES.feature_loaded?(path)`); but since the behaviour is similar to `Array#include?`, I'd suggest re-using it (and stay backward compatible). -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115491] [Ruby master Feature#20024] SyntaxError subclasses
by kddnewton (Kevin Newton) 10 Jan '24

10 Jan '24

Issue #20024 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #20024: SyntaxError subclasses https://bugs.ruby-lang.org/issues/20024 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- There are many places around the Ruby ecosystem that handle syntax errors in different ways. Some provide highlighting, others provide recovery of some form, still more provide LSP metadata. In order to provide more rich information, most of them switch on the message of the error being returned, as in: https://github.com/ruby/irb/blob/f86d9dbe2fc05ed62332069a27f4aacc59ba9634/l… Within ruby/spec, specific error messages are required for these kinds of messages in order to support this implicit interface that syntax errors have a hidden type, which is only expressed through their message. For example: https://github.com/ruby/spec/blob/c3206f644325c026fc5b700f0ea75ce9bd2e9d02/… https://github.com/ruby/spec/blob/c3206f644325c026fc5b700f0ea75ce9bd2e9d02/… https://github.com/ruby/spec/blob/c3206f644325c026fc5b700f0ea75ce9bd2e9d02/… https://github.com/ruby/spec/blob/c3206f644325c026fc5b700f0ea75ce9bd2e9d02/… https://github.com/ruby/spec/blob/c3206f644325c026fc5b700f0ea75ce9bd2e9d02/… It's not clear from these specs or from the parser itself which error messages are permanent/guaranteed versus which are changeable. Either way, relying on the error message itself as opposed to the type of the error is brittle at best. I would like to suggest instead we implement subclasses on `SyntaxError` that would allow tools that depend on specific syntax errors to rescue those subclasses instead of parsing the message. In addition to alleviating the need to parse error messages with regex, this would also allow for the possibility that the error messages could change in the future without breaking external tooling. Allowing these to change would allow them to be potentially enhanced or changed by other tools - for example by providing recovery information or translating them. This is particularly important for Prism since we are getting down to individual spec failures and some of the failures are related to the fact that we have messages like `"Numbered parameter is already used in outer scope"` where the spec requires `/numbered parameter is already used in/`. Even this case-sensitivity is causing failures, which seems like we're testing the wrong thing. -- https://bugs.ruby-lang.org/

9 16

[ruby-core:116152] [Ruby master Feature#20176] Array#pack: support offset kwarg
by chucke (Tiago Cardoso) 10 Jan '24

10 Jan '24

Issue #20176 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Feature #20176: Array#pack: support offset kwarg https://bugs.ruby-lang.org/issues/20176 * Author: chucke (Tiago Cardoso) * Status: Open * Priority: Normal ---------------------------------------- I was changing some code to use ruby 3.3's new `buffer` kwarg (great addition btw!) when using `Array#pack`. There are a few cases however, where I could perform the change, as not all my usages rely on appending; in some, I'm actually prepending it. To solve this, I'd like to propose the `offset` kwarg, which declares where to add the resulting string. picking up on example from the docs: [65, 66].pack('C*', buffer: 'foo') # => "fooAB" [65, 66].pack('C*', buffer: 'foo', offset: 0) # => "ABfoo" [65, 66].pack('C*', buffer: 'foo', offset: 1) # => "fABoo" -- https://bugs.ruby-lang.org/

2 2

[ruby-core:116140] [Ruby master Bug#20175] Broken File.dirname(__FILE__) in eval blocks
by kiskoza (Zsolt Kozaroczy) 10 Jan '24

10 Jan '24

Issue #20175 has been reported by kiskoza (Zsolt Kozaroczy). ---------------------------------------- Bug #20175: Broken File.dirname(__FILE__) in eval blocks https://bugs.ruby-lang.org/issues/20175 * Author: kiskoza (Zsolt Kozaroczy) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Since #19755 eval use caller location by default, however, it broke `File.dirname(__FILE__)` in some cases. ```ruby # eval.rb eval('puts file: __FILE__, dirname: File.dirname(__FILE__)') ``` Up to Ruby 3.2.2 it gave back the same results, even if it wasn't technically correct in some cases ```bash ## Ruby 3.2.2 ruby eval.rb # {:file=>"(eval)", :dirname=>"."} ruby ./eval.rb # {:file=>"(eval)", :dirname=>"."} cd folder && ruby ../eval.rb # {:file=>"(eval)", :dirname=>"."} # This one is not pointing to the right directory, but still returns a valid path ruby /Codes/eval.rb # {:file=>"(eval)", :dirname=>"."} # This one is not pointing to the right directory, but still returns a valid path ``` In Ruby 3.3.0 (introduced in commit:43a5c19135), it gives back different paths, trying to point to the right directory, but it has the `(eval at ` prefix which makes it broken for codes expecting a valid path. ```bash ## Ruby 3.3.0 ruby eval.rb # {:file=>"(eval at eval.rb:1)", :dirname=>"."} ruby ./eval.rb # {:file=>"(eval at ./eval.rb:1)", :dirname=>"(eval at ."} # Broken path cd folder && ruby ../eval.rb # {:file=>"(eval at ../eval.rb:1)", :dirname=>"(eval at .."} # This one is trying to point to the right directory, but it has a broken syntax ruby /Codes/eval.rb # {:file=>"(eval at /Codes/eval.rb:1)", :dirname=>"(eval at /Codes"} # This one is trying to point to the right directory, but it has a broken syntax ``` I was able to reproduce it on current master as well. -- https://bugs.ruby-lang.org/

3 4