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

[ruby-core:116906] [Ruby master Feature#20291] Add --warning=category option the same as -W:category
by nobu (Nobuyoshi Nakada) 22 Feb '24

22 Feb '24

Issue #20291 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #20291: Add --warning=category option the same as -W:category https://bugs.ruby-lang.org/issues/20291 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I propose a `--warning` option that corresponds to the `-W` option, like the `--encoding` option to the `-E` option. The argument after `--warning=` is same as `-W:`. https://github.com/ruby/ruby/pull/4113 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:116681] [Ruby master Misc#20260] ISEQ flag for prism compiler
by kddnewton (Kevin Newton) 21 Feb '24

21 Feb '24

Issue #20260 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20260: ISEQ flag for prism compiler https://bugs.ruby-lang.org/issues/20260 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- In order to support error highlight, there's needs to be a way to tell which compiler generated an instruction sequence (compile.c or prism_compile.c). That's because when the file is reparsed to find the node based on the node id, we need to know which parser to use. We can't look at the current parser because it may have been dumped to binary and the parser/compile pair might not match up to the current running process. I would like to add a flag to `rb_iseq_constant_body` that indicates it came from prism, as well as the `:prism` hash key to the misc hash in the array form of iseqs. This will allow us to determine the source of the iseq from both C and Ruby. Since this is user-facing (albeit from an experimental library that shouldn't be relied upon) I wanted to make sure this way okay before merging. -- https://bugs.ruby-lang.org/

4 14

[ruby-core:116853] [Ruby master Feature#20282] Enhancing Ruby's Coverage with Per-Test Coverage Reports
by ioquatix (Samuel Williams) 20 Feb '24

20 Feb '24

Issue #20282 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #20282: Enhancing Ruby's Coverage with Per-Test Coverage Reports https://bugs.ruby-lang.org/issues/20282 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As Ruby applications grow in complexity, the need for more sophisticated testing and coverage analysis tools becomes paramount. Current coverage tools in Ruby offer a good starting point but fall short in delivering the granularity and flexibility required by modern development practices. Specifically, there is a significant gap in "per-test coverage" reporting, which limits developers' ability to pinpoint exactly which tests exercise which lines of code. This proposal seeks to initiate a discussion around improving Ruby's coverage module to address this gap. ## Objectives The primary goal of this initiative is to introduce support for per-test coverage reports within Ruby, focusing on three key areas: 1. Scoped Coverage Data Capture: Implementing the capability to capture coverage data within user-defined scopes, such as global, thread, or fiber scopes. This would allow for more granular control over the coverage analysis process. 2. Efficient Data Capture Controls: Developing mechanisms to efficiently control the capture of coverage data. This includes the ability to exclude specific files, include/ignore/merge eval'd code, to ensure that the coverage data is both relevant and manageable. 3. Compatibility and Consistency: Ensuring that the coverage data is exposed in a manner that is consistent with existing coverage tools and standards. This compatibility is crucial for integrating with a wide array of tooling and for facilitating a seamless developer experience. ## Proposed Solutions The heart of this proposal lies in the introduction of a new subclassable component within the Coverage module, tentatively named `Coverage::Capture`. This component would allow users to define custom coverage capture behaviors tailored to their specific needs. Below is a hypothetical interface for such a mechanism: ```ruby class Coverage::Capture def self.start self.new.tap(&:start) end # Start receiving coverage callbacks. def start end # Stop receiving coverage callbacks. def stop end # User-overridable statement coverage callback. def statement(iseq, location) fetch(iseq)&.statement_coverage.increment(location) end # Additional methods for branch/declaration coverage would follow a similar pattern. end class MyCoverageCapture < Coverage::Capture # Provides efficient data capture controls - can return nil if skipping coverage for this iseq, or can store coverage data per-thread, per-fiber, etc. def fetch(iseq) @coverage[iseq] ||= Coverage.default_coverage(iseq) end end # Usage example: my_coverage_capture = MyCoverageCapture.start # Execute test suite or specific tests my_coverage_capture.stop # Access detailed coverage data puts my_coverage_capture.coverage.statement_coverage ``` In addition, we'd need a well defined interface for `Coverage.default_coverage`, which includes line, branch and declaration coverage statistics. I suggest we take inspiration from the proposed interface defined by the vscode text editor: https://github.com/microsoft/vscode/blob/b44593a612337289c079425a5b2cc70102… - this interface was designed to be compatible with a wide range of coverage libraries, so represents the intersection of that functionality. ```ruby # Hypothetical interface (mostly copied from vscode's proposed interface): module Coverage # Contains coverage metadata for a file class Target attr_reader :instruction_sequence attr_accessor :statement_coverage, :branch_coverage, :declaration_coverage, :detailed_coverage def initialize(instruction_sequence, statement_coverage, branch_coverage=nil, declaration_coverage=nil) @instruction_sequence = instruction_sequence @statement_coverage = statement_coverage @branch_coverage = branch_coverage @declaration_coverage = declaration_coverage end end # Coverage information for a single statement or line. class StatementCoverage # The number of times this statement was executed, or a boolean indicating # whether it was executed if the exact count is unknown. If zero or false, # the statement will be marked as un-covered. attr_accessor :executed # Statement location (line number? or range? or position? AST?) attr_accessor :location # Coverage from branches of this line or statement. If it's not a # conditional, this will be empty. attr_accessor :branches # Initializes a new instance of the StatementCoverage class. # # @parameter executed [Number, Boolean] The number of times this statement was executed, or a # boolean indicating whether it was executed if the exact count is unknown. If zero or false, # the statement will be marked as un-covered. # # @parameter location [Position, Range] The statement position. # # @parameter branches [Array(BranchCoverage)] Coverage from branches of this line. # If it's not a conditional, this should be omitted. def initialize(executed, location, branches=[]) @executed = executed @location = location @branches = branches end end # Coverage information for a branch class BranchCoverage # The number of times this branch was executed, or a boolean indicating # whether it was executed if the exact count is unknown. If zero or false, # the branch will be marked as un-covered. attr_accessor :executed # Branch location. attr_accessor :location # Label for the branch, used in the context of "the ${label} branch was # not taken," for example. attr_accessor :label # Initializes a new instance of the BranchCoverage class. # # @param executed [Number, Boolean] The number of times this branch was executed, or a # boolean indicating whether it was executed if the exact count is unknown. If zero or false, # the branch will be marked as un-covered. # # @param location [Position, Range] (optional) The branch position. # # @param label [String] (optional) Label for the branch, used in the context of # "the ${label} branch was not taken," for example. def initialize(executed, location=nil, label=nil) @executed = executed @location = location @label = label end end # Coverage information for a declaration class DeclarationCoverage # Name of the declaration. Depending on the reporter and language, this # may be types such as functions, methods, or namespaces. attr_accessor :name # The number of times this declaration was executed, or a boolean # indicating whether it was executed if the exact count is unknown. If # zero or false, the declaration will be marked as un-covered. attr_accessor :executed # Declaration location. attr_accessor :location # Initializes a new instance of the DeclarationCoverage class. # # @param name [String] Name of the declaration. # # @param executed [Number, Boolean] The number of times this declaration was executed, or a # boolean indicating whether it was executed if the exact count is unknown. If zero or false, # the declaration will be marked as un-covered. # # @param location [Position, Range] The declaration position. def initialize(name, executed, location) @name = name @executed = executed @location = location end end end ``` -- https://bugs.ruby-lang.org/

3 6

[ruby-core:116516] [Ruby master Bug#20229] Empty keyword splat in array not removed in ARGSPUSH case
by jeremyevans0 (Jeremy Evans) 20 Feb '24

20 Feb '24

Issue #20229 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #20229: Empty keyword splat in array not removed in ARGSPUSH case https://bugs.ruby-lang.org/issues/20229 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- For the following code: ```ruby a = [] kw = {} [*a, **kw] ``` Ruby 2.0-3.3 return `[{}]`, when the desired result (since 2.7) is `[]`. I discovered this while working on an optimization for the ARGSCAT case, where `[*a, 1, **kw]` allocates two arrays instead of a single array. My optimization fixes that by adding a `pushtoarraykwsplat` instruction as a replacement for `newarraykwsplat`. I've used `pushtoarraykwsplat` in the ARGSPUSH case to fix this bug. My pull request for the bug fix and optimization: https://github.com/ruby/ruby/pull/9766 -- https://bugs.ruby-lang.org/

1 2

[ruby-core:116676] [Ruby master Bug#20258] Socket::IPV6_RECVERR for IPv6
by marek22k 20 Feb '24

20 Feb '24

Issue #20258 has been reported by marek22k (Marek Küthe). ---------------------------------------- Bug #20258: Socket::IPV6_RECVERR for IPv6 https://bugs.ruby-lang.org/issues/20258 * Author: marek22k (Marek Küthe) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hello, I am currently trying to receive ICMP error messages in Ruby. For IPv4 there is the `Socket::IP_RECVERR` flag, which can be set, but not for IPv6 (not found unter https://docs.ruby-lang.org/en/3.2/Socket/Constants.html for example), although this is provided for in POSIX (see https://manned.org/ipv6.7 under IPV6_RECVERR). The following can therefore be done for IPv4: ```rb sock.setsockopt Socket::IPPROTO_IP, Socket::IP_RECVERR, 1 ``` But not for IPv6: ``` sock.setsockopt Socket::IPPROTO_IPV6, Socket::IPV6_RECVERR, 1 ``` Could IPV6_RECVERR be included? Background: I want to try to build a traceroute implementation in Ruby. So far I have the following code: ```rb # frozen_string_literal: true # sharable_constant_value: literal require 'socket' sock = Socket.open(Socket::AF_INET6, Socket::SOCK_DGRAM, Socket::IPPROTO_UDP) sock.setsockopt Socket::IPPROTO_IPV6, Socket::IPV6_UNICAST_HOPS, 1 # sock.setsockopt Socket::IPPROTO_IPV6, Socket::IPV6_RECVERR, 1 dest = Socket.sockaddr_in 33435, '2a00:1450:4001:806::2003' pp sock.send "Test", 0, dest pp sock.recvmsg nil, Socket::MSG_ERRQUEUE ``` However, the `recvmsg` function is blocking (still receiving the ICMP error message) forever. I could imagine that this is due to the missing flag. Hence this request. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:116878] [Ruby master Bug#18988] Ripper cannot parse some code that has regexp named capture
by yui-knk (Kaneko Yuichiro) 20 Feb '24

20 Feb '24

Issue #18988 has been updated by yui-knk (Kaneko Yuichiro). Status changed from Open to Closed This is solved by https://bugs.ruby-lang.org/issues/20257 (https://github.com/ruby/ruby/pull/9923) ---------------------------------------- Bug #18988: Ripper cannot parse some code that has regexp named capture https://bugs.ruby-lang.org/issues/18988#change-106913 * Author: tompng (tomoya ishida) * Status: Closed * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-08-29T15:47:09Z :detached: cd7506593a) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Ripper does not seems to recognize regexp named capture defining new local variables, fails to parse some code. ~~~ruby requie 'ripper' # expect syntax ok, got syntax error Ripper.sexp("/(?<a>)/ =~ ''; x = a **a, a if false") # expect syntax error, got syntax ok Ripper.sexp("/(?<a>)/ =~ ''; x = a **a, **a if false") # "exit" is a method call, got string_literal Ripper.sexp("/(?<a>)/ =~ ''; a %(exit)") ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115678] [Ruby master Bug#20055] Ripper seems to skip some checks like `void value expression` and `duplicated variable name`
by tompng (tomoya ishida) 20 Feb '24

20 Feb '24

Issue #20055 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20055: Ripper seems to skip some checks like `void value expression` and `duplicated variable name` https://bugs.ruby-lang.org/issues/20055 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-08T07:01:01Z master f2c84c4884) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- These are syntax error ~~~ruby return + return # void value expression 1 in [a, a] # duplicated variable name 1 + (1 => [a, a]) # both ~~~ But Ripper.sexp returns S-expression, not nil ~~~ruby Ripper.sexp 'return + return' # => [:program, [[:return, [:args_add_block, [[:unary, :+@, [:return0]]], false]]]] Ripper.sexp '1 in [a, a]' # => [:program, [[:case, [:@int, "1", [1, 0]], [:in, [:aryptn, nil, [[:var_field, [:@ident, "a", [1, 6]]], [:var_field, [:@ident, "a", [1, 9]]]], nil, nil], nil, nil]]]] Ripper.sexp '1 + (1 => [a, a]) # both' # => [:program, [[:binary, [:@int, "1", [1, 0]], :+, [:paren, [[:case, [:@int, "1", [1, 5]], [:in, [:aryptn, nil, [[:var_field, [:@ident, "a", [1, 11]]], [:var_field, [:@ident, "a", [1, 14]]]], nil, nil], nil, nil]]]]]]] ~~~ -- https://bugs.ruby-lang.org/

2 1

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

20 Feb '24

Issue #18576 has been updated by Eregon (Benoit Daloze). `BINARY (ASCII-8BIT)` seems a good compromise. The `/` seems potentially confusing for: `incompatible character encodings: BINARY / ASCII-8BIT and EUC-JP (Encoding::CompatibilityError)`. So I think using parenthesis is OK and clearer than `/`. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106910 * 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:116871] [Ruby master Bug#20284] Regexp::TimeoutError is not triggered by a specific Regexp
by jbeschi (jacopo beschi) 20 Feb '24

20 Feb '24

Issue #20284 has been reported by jbeschi (jacopo beschi). ---------------------------------------- Bug #20284: Regexp::TimeoutError is not triggered by a specific Regexp https://bugs.ruby-lang.org/issues/20284 * Author: jbeschi (jacopo beschi) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I've noticed that the Regexp::TimeoutError is not triggered for this Regexp: ```ruby jacopo-37s-mb 3.3.0 ~ cat fail.rb require 'benchmark' p RUBY_DESCRIPTION Regexp.timeout = 0.1 puts "Regexp.timeout: #{Regexp.timeout}" re = /((a|aa)+)+b/ 10.times do p Benchmark.realtime { re.match?("a" * 900000000) } end ``` ``` jacopo-37s-mb 3.3.0 ~ ruby fail.rb "ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin22]" Regexp.timeout: 0.1 1.1425850000232458 1.0082139987498522 1.064377998933196 1.0745620001107454 1.0647990014404058 1.6172770000994205 1.396629998460412 1.2450549993664026 1.3292079996317625 1.5961690004915 ``` -- https://bugs.ruby-lang.org/

2 2

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

20 Feb '24

Issue #18576 has been updated by byroot (Jean Boussier). ``` >> "fée" + "fée".b (irb):8:in `+': incompatible character encodings: UTF-8 and BINARY (ASCII-8BIT) (Encoding::CompatibilityError) ``` I don't mind `BINARY` being first or last. I'll adjust my PR. As for the consecutive parentheteses, what about: ``` >> "fée" + "fée".b (irb):8:in `+': incompatible character encodings: UTF-8 and BINARY / ASCII-8BIT (Encoding::CompatibilityError) ``` ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106903 * 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