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

[ruby-core:116313] [Ruby master Feature#16495] Inconsistent quotes in error messages
by mame (Yusuke Endoh) 19 Jan '24

19 Jan '24

Issue #16495 has been updated by mame (Yusuke Endoh). I prototyped it: https://github.com/ruby/ruby/pull/9608 Still need to update prism and ruby/spec. For information in impact assessment: this change made 140 tests fail in `make test-all`. Many of them examined error messages, which could be fixed by simply updating the expected regular expression. But there were some non-trivial effects, e.g., irb converts the error message from `` `top (required)' `` to `` `<main>' ``, so this conversion code is also updated. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106337 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116312] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by mame (Yusuke Endoh) 19 Jan '24

19 Jan '24

Issue #19117 has been updated by mame (Yusuke Endoh). I prototyped this proposal: https://github.com/ruby/ruby/pull/9605 Fortunately, this would bring neither perrformance degredation nor extra memory usage when an exception is raised because I just replaced the method id with the method entry object in Thread::Backtrace::Location. (To get the method id, we need to read it via the method entry object, but I believe it is ignorable.) The notation is as follows. * Instance methods of named classes are `ClassName#method_name`. * Class methods for named classes are `ClassName.method_name`. * Only `method_name` otherwise I think I properly support `block in ClassName#method_name` and so on. ``` $ cat test.rb def toplevel = raise class Foo def self.class_meth = toplevel def instance_meth = Foo.class_meth end obj = Foo.new def obj.singleton_meth = instance_meth obj.singleton_meth $ ./miniruby test.rb test.rb:1:in 'Object#toplevel': unhandled exception from test.rb:4:in 'Foo.class_meth' from test.rb:6:in 'Foo#instance_meth' from test.rb:11:in 'singleton_meth' from test.rb:13:in '<main>' ``` @byroot What do you think? This causes some tests to fail, but I haven't fixed the test yet. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-106336 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116310] [Ruby master Feature#16495] Inconsistent quotes in error messages
by mame (Yusuke Endoh) 18 Jan '24

18 Jan '24

Issue #16495 has been updated by mame (Yusuke Endoh). Let me add a little to the matz's decision. At the dev meeting, he said that we will replace with a single quote, not only the backticks for `NameError#message`, but also the ones for other exception messages (e.g., ``no superclass method `foo'``) and the ones surrounding the names of methods in the backtrace (e.g., ``from test.rb:2:in `foo'``). Matz also wants to experiment with #19117 as well, and I am writing an experimental patch for that. If this is also applied, each line of the backtrace will be ``` before: from test.rb:9:in `foo' after : from test.rb:9:in `Kernel#p' ``` We recognize that both this ticket and #19117 are not small incompatibilities, so if they actually change, it would be nice to change them both at once. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106334 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116299] [Ruby master Feature#16495] Inconsistent quotes in error messages
by Eregon (Benoit Daloze) 18 Jan '24

18 Jan '24

Issue #16495 has been updated by Eregon (Benoit Daloze). Great to see progress on this issue. Agreed, for method names and file names, single quotes are best. Backticks are best for quoting source code, and there is no source code in Ruby backtraces. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106321 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

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

18 Jan '24

Issue #18576 has been updated by Eregon (Benoit Daloze). I think everyone's opinion on the thread is pretty clear and not everyone agrees, that's fine. @matz Could you decide whether it's OK to experiment with the Encoding#name changing to "BINARY" or not? If not, is @byroot's proposal in https://bugs.ruby-lang.org/issues/18576#note-33 accepted? ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106320 * 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:116296] [Ruby master Feature#16495] Inconsistent quotes in error messages
by Dan0042 (Daniel DeLorme) 18 Jan '24

18 Jan '24

Issue #16495 has been updated by Dan0042 (Daniel DeLorme). I'd like something that's convenient to copy-paste. Testing: with single quote pair: undefined local variable or method 'foobar' for main:Object (NameError) `undefined local variable or method 'foobar' for main:Object (NameError)` ``undefined local variable or method 'foobar' for main:Object (NameError)`` with backtick pair: undefined local variable or method `foobar` for main:Object (NameError) `undefined local variable or method `foobar` for main:Object (NameError)` ``undefined local variable or method `foobar` for main:Object (NameError)`` At first I preferred backticks but given how the above are rendered in markdown I've ended up preferring single quotes. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106318 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116295] [Ruby master Feature#16495] Inconsistent quotes in error messages
by matz (Yukihiro Matsumoto) 18 Jan '24

18 Jan '24

Issue #16495 has been updated by matz (Yukihiro Matsumoto). I agree with giving up backquotes. I'd rather use single quote pairs, unless any compatibility issues are caused. Matz. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106317 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116134] [Ruby master Bug#20174] Ruby 3.2 jit_cont_free segfault with YJIT enabled
by ziggythehamster (Keith Gable) 18 Jan '24

18 Jan '24

Issue #20174 has been reported by ziggythehamster (Keith Gable). ---------------------------------------- Bug #20174: Ruby 3.2 jit_cont_free segfault with YJIT enabled https://bugs.ruby-lang.org/issues/20174 * Author: ziggythehamster (Keith Gable) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ruby 3.2 segfaults reproducibly for us on aarch64 (Graviton2) and x86_64 with YJIT enabled ... however all of my attempts to make a minimal reproducible test case have failed. The control frame of the segfault isn't consistent, but the C backtrace is. It doesn't occur in 3.3, so I used the backtrace to find the function (jit_cont_free) and compare it between 3.2 and 3.3. The only change that seemed like a plausible candidate was a one-line guard added by k0kubun in e07e9f8491d9ab8b22d2bdf6a8aeba834dac7eef, so I added .patch to the end of the URL on GitHub and added that as a patch against 3.2. This resolved the problem. I would therefore suggest backporting that change from 3.3 to 3.2 :). The change that triggered this is a two line change to a gemspec (that we need to refactor) that we made because Rake released a new version, which I will censor and annotate below: ``` # frozen_string_literal: true $LOAD_PATH.push File.expand_path('lib', __dir__) require 'rubygems/dependency_installer' # before: Gem::DependencyInstaller.new.install(Gem::Dependency.new('rake')) # after: Gem::DependencyInstaller.new.install(Gem::Dependency.new('rake', '~> 13.1.0')) require 'rake/file_list' Gem::Specification.new do |spec| spec.name = 'censored' spec.version = '0.0.1.pre' spec.author = 'censored' spec.email = 'censored' spec.summary = 'censored' spec.description = 'censored' spec.homepage = 'censored' spec.license = 'All rights reserved' spec.required_ruby_version = '>= 2.6.0' spec.metadata['homepage_uri'] = spec.homepage gitignore = File.read('.gitignore').lines.reject { |l| l.match?(/\A\s*#/) || l.match?(/\A\s*\z/) }.map(&:chomp) spec.files = Rake::FileList.new('\.[a-zA-Z0-9]*', '\.[a-zA-Z0-9]*/*', '**/*') .exclude(gitignore) .reject { |f| File.directory?(f) || f.match(%r{\A(test|spec|features|vendor|.git|.bundle)/}) } to_include = gitignore.select { |l| l.match?(/\A\s*!/) }.map { |l| l.delete_prefix('!') } spec.files += Rake::FileList.new(to_include).reject { |f| File.directory?(f) } spec.require_paths = ['lib'] spec.add_development_dependency 'awesome_print', '~> 1.8.0' spec.add_development_dependency 'pry', '~> 0.14.2' # before: spec.add_development_dependency 'rake', '~> 13.0.1' # after: spec.add_development_dependency 'rake', '~> 13.1.0' spec.add_development_dependency 'rdoc', '~> 6.3.1' spec.add_development_dependency 'rspec', '~> 3.11.0' spec.add_development_dependency 'rspec_junit_formatter', '~> 0.5.1' spec.add_development_dependency 'rubocop', '~> 1.39.0' spec.add_development_dependency 'rubocop-packaging', '~> 0.5.2' spec.add_development_dependency 'rubocop-rake', '~> 0.6.0' spec.add_development_dependency 'rubocop-rspec', '~> 2.12.1' spec.add_development_dependency 'simplecov', '~> 0.21.2' spec.add_development_dependency 'simplecov-cobertura', '~> 2.1.0' spec.add_development_dependency 'yard', '~> 0.9.25' spec.add_runtime_dependency 'activesupport', '>= 5.1.7', '< 8' spec.add_runtime_dependency 'censored-m', '~> 0.1.72' spec.add_runtime_dependency 'censored-r', '~> 0.1.175' spec.add_runtime_dependency 'aws-sdk-athena', '~> 1.43' spec.add_runtime_dependency 'aws-sdk-cloudwatch', '~> 1.5' spec.add_runtime_dependency 'aws-sdk-core', '~> 3.122' spec.add_runtime_dependency 'aws-sdk-dynamodb', '~> 1.5' spec.add_runtime_dependency 'aws-sdk-firehose', '~> 1.1' spec.add_runtime_dependency 'aws-sdk-glue', '~> 1.108' spec.add_runtime_dependency 'aws-sdk-kinesis', '~> 1.13' spec.add_runtime_dependency 'aws-sdk-redshift', '~> 1.2' spec.add_runtime_dependency 'aws-sdk-s3', '~> 1.9' spec.add_runtime_dependency 'aws-sdk-sns', '~> 1.3' spec.add_runtime_dependency 'aws-sdk-sqs', '~> 1.3' spec.add_runtime_dependency 'aws-sdk-ssm', '~> 1.76' spec.add_runtime_dependency 'concurrent-ruby', '>= 1.1.5' spec.add_runtime_dependency 'dry-configurable', '~> 0.13' end ``` However, I cannot turn this gemspec into a reproducer on my end. The smallest change makes the segfault go away. To avoid a gigantic issue description, I have attached the censored segfault backtraces and the RbConfig from the x86_64 build (since I'm compiling my own Ruby). I'll note again that while aarch64 and x86_64 appear to have failed while doing something in optparse this time, it appears random (or more likely: GC pressure related). I've also seen it fail when doing a require_relative much earlier. It always fails with the same C backtrace. I have absolutely no idea why `cont` might be NULL. The backtrace shows it is called by `cont_free`, which has a `VM_ASSERT` for detecting this condition. Obviously, there must be some situation where jit_cont becomes NULL due to YJIT, but I have no idea what that situation is. In case someone thinks this might be compiler/compiler option related, I am using the following: * Amazon Linux 2 * LLVM/Clang 11 except that because Amazon Linux doesn't ship lld, we are using `gcc10-ld.gold` as the linker * rustc 1.68.2 (9eb3afe9e 2023-03-27) (Amazon Linux 1.68.2-1.amzn2.0.3) * OpenSSL 3.0.12 (self-compiled with corp-dictated hardened configuration options ... I can share if someone thinks this is relevant) * `extra_warnflags="-Wno-address-of-packed-member -Wno-declaration-after-statement -Wno-register"` * aarch64: `optflags="-O3 -mcpu=neoverse-n1"` * x86_64: `optflags="-O3 -march=sandybridge"` ---Files-------------------------------- bt_aarch64.txt (34.5 KB) bt_x86_64.txt (30.3 KB) rbconfig_x86_64.txt (9.36 KB) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:115594] [Ruby master Bug#20042] ObjectSpace finalizer can cause segfault
by ioquatix (Samuel Williams) 18 Jan '24

18 Jan '24

Issue #20042 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20042: ObjectSpace finalizer can cause segfault https://bugs.ruby-lang.org/issues/20042 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby class Finalizer def call # <- missing (id) argument end end object = Object.new ObjectSpace.define_finalizer(object, Finalizer.new) object = nil GC.start # segfaults here ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:116280] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by Dan0042 (Daniel DeLorme) 18 Jan '24

18 Jan '24

Issue #18576 has been updated by Dan0042 (Daniel DeLorme). tenderlovemaking (Aaron Patterson) wrote in #note-7: > I think this example should raise an exception: > > ```ruby > u = (b = "abcde".force_encoding('ASCII-8BIT')).encode('UTF-8') > ``` I'm worried about the above misconception. No, this example shouldn't raise an exception, because being ascii-compatible is the entire reason there's "ASCII" in "ASCII-8BIT". If even @tenderlovemaking can have this misconception, I would wager it's a fairly common one. And if the encoding was renamed to "BINARY" it would further encourage the misconception. We'd wind up with a kind of Frankenstein encoding that pretends to be true binary by its name, but having the behavior of ascii-compatible encodings. This thread has several people currently agreeing that the ascii-compatible behavior should not change, but if the name was changed I can easily predict some people will call for a change in behavior because the name "binary" has that overtone. zverok (Victor Shepelev) wrote in #note-34: > For better or worse, we break compatibility constantly. > One of the recent telling examples was the removal of `File.exists?` I won't say we can never break compatibility, but there's a very big qualitative difference here. If you run into `File.exists?`, the program simply crashes with NoMethodError. If you run into `enc.name == "ASCII-8BIT"` the return value changes from true to false; the program may crash later or not, the bug can remain undetected for a long time, there's a potential for corrupted data. This is 2-3 orders of magnitude harder to debug than NoMethodError. Even if not many people are affected by this, it's a very nasty kind of incompatibility. byroot (Jean Boussier) wrote in #note-15: > We could keep `Encoding#name` as `"ASCII-8BIT"`, but change `Encoding#inspect` and make sure `EncodingError` use the `BINARY` name in its error messages. I would really like that. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106302 * 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