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

[ruby-core:116802] [Ruby master Misc#20272] Ambiguity around Ractor message sending FIFO semantics

by forthoney (Seong-Heon Jung)

Issue #20272 has been reported by forthoney (Seong-Heon Jung). ---------------------------------------- Misc #20272: Ambiguity around Ractor message sending FIFO semantics https://bugs.ruby-lang.org/issues/20272 * Author: forthoney (Seong-Heon Jung) * Status: Open * Priority: Normal ---------------------------------------- The docs should explicitly state the semantics/properties of Ractor message, especially when it comes to FIFO. For example, assume I have two Ractors, Ractor A and Ractor B. Ractor A sends two messages `"hello"` and `"world"` in this order to Ractor B. If I call `Ractor.receive` on Ractor B, am I guaranteed to see `"hello"` and then `"world"` or is it possible the messages are delivered out of order? -- https://bugs.ruby-lang.org/

17 hours, 26 minutes

2
1
0 0

[ruby-core:116218] [Ruby master Bug#20186] Ripper does not generate AST for some keywords in Ruby 3.3

by kzkn (Kazuki Nishikawa)

Issue #20186 has been reported by kzkn (Kazuki Nishikawa). ---------------------------------------- Bug #20186: Ripper does not generate AST for some keywords in Ruby 3.3 https://bugs.ruby-lang.org/issues/20186 * Author: kzkn (Kazuki Nishikawa) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ripper does not generate AST for the below keyword: - break - next - redo - retry - yield Ruby 3.2 ``` $ ruby -v ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] $ ruby -rripper -e "p Ripper.sexp('break')" [:program, [[:break, []]]] $ ruby -rripper -e "p Ripper.sexp('next')" [:program, [[:next, []]]] $ ruby -rripper -e "p Ripper.sexp('redo')" [:program, [[:redo]]] $ ruby -rripper -e "p Ripper.sexp('retry')" [:program, [[:retry]]] $ ruby -rripper -e "p Ripper.sexp('yield')" [:program, [[:yield0]]] ``` Ruby 3.3 ``` $ ruby -v ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] $ ruby -rripper -e "p Ripper.sexp('break')" nil $ ruby -rripper -e "p Ripper.sexp('next')" nil $ ruby -rripper -e "p Ripper.sexp('redo')" nil $ ruby -rripper -e "p Ripper.sexp('retry')" nil $ ruby -rripper -e "p Ripper.sexp('yield')" nil ``` -- https://bugs.ruby-lang.org/

2 days, 12 hours

2
1
0 0

[ruby-core:116687] [Ruby master Bug#20262] Regex mismatch between Ruby 3.2.2 and 3.3.0

by weilandia (Nick Weiland)

Issue #20262 has been reported by weilandia (Nick Weiland). ---------------------------------------- Bug #20262: Regex mismatch between Ruby 3.2.2 and 3.3.0 https://bugs.ruby-lang.org/issues/20262 * Author: weilandia (Nick Weiland) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This might be a duplicate of https://bugs.ruby-lang.org/issues/20098, but I cannot make it match with the backref so maybe not. Below example matches in 3.2.2 but not in 3.3.0 ``` ruby str = "------------abcdefg------------#3895912" re = /()\1\b\w*[a-zA-Z-]*\d+[\w-]{3,}\w+\b/ re.match?(str) ``` -- https://bugs.ruby-lang.org/

3 days, 3 hours

2
2
0 0

[ruby-core:116039] [Ruby master Bug#20154] aarch64: configure overrides `-mbranch-protection` if it was set in CFLAGS via environment

by jprokop (Jarek Prokop)

Issue #20154 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Bug #20154: aarch64: configure overrides `-mbranch-protection` if it was set in CFLAGS via environment https://bugs.ruby-lang.org/issues/20154 * Author: jprokop (Jarek Prokop) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Recently a GH PR was merged <https://github.com/ruby/ruby/pull/9306> For PAC/BTI support on ARM CPUs for Coroutine.S. Without proper compilation support in configure.ac it segfaults Ruby with fibers on CPUs where PAC is supported: https://bugs.ruby-lang.org/issues/20085 At the time of writing, configure.ac appends the first option from a list for flag `-mbranch-protection` that successfully compiles a program <https://github.com/ruby/ruby/blob/master/configure.ac#L829>, to XCFLAGS and now also ASFLAGS to fix issue 20085 for Ruby master. This is suboptimal for Fedora as we set -mbranch-protection=standard by default in C{,XX}FLAGS: ``` CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer ' export CFLAGS CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer' export CXXFLAGS ``` And the appended flag overrides distribution's compilation configuration, which in this case ends up omitting BTI instructions and only using PAC. Would it make sense to check if such flags exist and not overwrite them if they do? Serious proposals: 1. Simplest fix that does not overwrite what is set in the distribution and results in higher security is simply prepending the list of options with `-mbranch-protection=standard`, it should cause no problems on ARMv8 CPUs and forward, BTI similarly to PAC instructions result into NOP, it is only extending the capability. See attached 0001-aarch64-Check-mbranch-protection-standard-first-to-u.patch 2. Other fix that sounds more sane IMO and dodges this kind of guessing where are all the correct places for the flag is what another Fedora contributor Florian Weimer suggested: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… "The reliable way to do this would be to compile a C file and check whether that enables __ARM_FEATURE_PAC_DEFAULT, and if that's the case, define a *different* macro for use in the assembler implementation. This way, you don't need to care about the exact name of the option." IOW instead of using __ARM_FEATURE_* directly in that code, define a macro in the style of "USE_PAC" with value of the feature if it is defined, I think that way we shouldn't need to append ASFLAGS anymore. However it's also important to catch the value of those macros as their values have meaning, I have an idea how to do that but I'd get on that monday earliest. ---Files-------------------------------- 0001-aarch64-Check-mbranch-protection-standard-first-to-u.patch (1004 Bytes) -- https://bugs.ruby-lang.org/

3 days, 19 hours

3
3
0 0

[ruby-core:116456] [Ruby master Feature#20215] Introduce `IO#readable?`

by ioquatix (Samuel Williams)

Issue #20215 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #20215: Introduce `IO#readable?` https://bugs.ruby-lang.org/issues/20215 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- There are some cases where, as an optimisation, it's useful to know whether more data is potentially available. We already have `IO#eof?` but the problem with using `IO#eof?` is that it can block indefinitely for sockets. Therefore, code which uses `IO#eof?` to determine if there is potentially more data, may hang. ```ruby def make_request(path = "/") client = connect_remote_host # HTTP/1.0 request: client.write("GET #{path} HTTP/1.0\r\n\r\n") # Read response client.gets("\r\n") # => "HTTP/1.0 200 OK\r\n" # Assuming connection close, there are two things the server can do: # 1. peer.close # 2. peer.write(...); peer.close if client.eof? # <--- Can hang here! puts "Connection closed" # Avoid yielding as we know there definitely won't be any data. else puts "Connection open, data may be available..." # There might be data available, so yield. yield(client) end ensure client&.close end make_request do |client| puts client.read # <--- Prefer to wait here. end ``` The proposed `IO#readable?` is similar to `IO#eof?` but rather than blocking, would simply return false. The expectation is the user will subsequently call `read` which may then wait. The proposed implementation would look something like this: ```ruby class IO def readable? !!self.closed? end end class BasicSocket # Is it likely that the socket is still connected? # May return false positive, but won't return false negative. def readable? return false unless super # If we can wait for the socket to become readable, we know that the socket may still be open. result = self.recv_nonblock(1, MSG_PEEK, exception: false) # No data was available - newer Ruby can return nil instead of empty string: return false if result.nil? # Either there was some data available, or we can wait to see if there is data avaialble. return !result.empty? || result == :wait_readable rescue Errno::ECONNRESET # This might be thrown by recv_nonblock. return false end end ``` For `IO` itself, when there is buffered data, `readable?` would also return true immediately, similar to `eof?`. This is not shown in the above implementation as I'm not sure if there is any Ruby method which exposes "there is buffered data". -- https://bugs.ruby-lang.org/

5 days, 7 hours

7
16
0 0

[ruby-core:117157] [Ruby master Misc#20336] DevMeeting-2024-04-17

by mame (Yusuke Endoh)

Issue #20336 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #20336: DevMeeting-2024-04-17 https://bugs.ruby-lang.org/issues/20336 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2024/04/17 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2024/04/14. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

1 week, 1 day

10
14
0 0

[ruby-core:117027] [Ruby master Bug#20319] Singleton class is being frozen lazily in some cases

by andrykonchin (Andrew Konchin)

Issue #20319 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #20319: Singleton class is being frozen lazily in some cases https://bugs.ruby-lang.org/issues/20319 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I've noticed suspicious behaviour (it doesn't affect anything in practice for me though) when an object becomes frozen only its own singleton class becomes frozen immediately. A singleton class of the immediate singleton class becomes frozen lazily after `#singleton_class` method call: ```ruby o = Object.new klass = o.singleton_class.singleton_class o.freeze puts klass.frozen? # false <== here we expect true puts o.singleton_class.singleton_class.frozen? # true puts klass.frozen? # true ``` I would expect all created singleton classes in an object singleton classes chain to become frozen immediately. -- https://bugs.ruby-lang.org/

1 week, 1 day

3
6
0 0

[ruby-core:117341] [Ruby master Feature#20396] ObjectSpace.dump_all(string_value: false): skip dumping the String contents

by byroot (Jean Boussier)

Issue #20396 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20396: ObjectSpace.dump_all(string_value: false): skip dumping the String contents https://bugs.ruby-lang.org/issues/20396 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- `ObjectSpace.dump_all` is a very useful method to debug memory leaks and such, hence is frequently needed in production. But since all the 7bit strings content is included in the dump, it incur the risk of leaking personal data, or secrets. Also, in many case the strings content isn't that helpful and is just making the dump much bigger for no good reason. And only pure-ASCII strings are dumped this way, which means all the tools that process these dumps should already be compatible with a dump without any string content. ### Feature I propose to add another optional parameter to `dump_all`: `string_value: false`. When passed, no String content is ever dumped regardless of its coderange. Implementation: https://github.com/ruby/ruby/pull/10382 cc @zzak -- https://bugs.ruby-lang.org/

1 week, 2 days

4
7
0 0

[ruby-core:116892] [Ruby master Misc#20287] DevMeeting before or after RubyKaigi

by duerst

Issue #20287 has been reported by duerst (Martin Dürst). ---------------------------------------- Misc #20287: DevMeeting before or after RubyKaigi https://bugs.ruby-lang.org/issues/20287 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal ---------------------------------------- RubyKaigi itself runs from May 15-17 (Wed-Fri) in Naha. It would be nice to have a DevMeeting before or afterwards. We should try to plan ahead, so that people can make the right flight and hotel reservations early. I have never been to Okinawa before and don't know any facilities that would be available. -- https://bugs.ruby-lang.org/

1 week, 2 days

2
2
0 0

[ruby-core:117240] [Ruby master Feature#20350] Return chilled string from Symbol#to_s

by Dan0042 (Daniel DeLorme)

Issue #20350 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20350: Return chilled string from Symbol#to_s https://bugs.ruby-lang.org/issues/20350 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- During Ruby 2.7 development there was an attempt to return a frozen string from Symbol#to_s (#16150#note-22) This had to be rolled back due to incompatibility, but now we have chilled strings (#20205) Symbol#to_s can safely return a chilled string, giving developers time to fix warnings before switching to a frozen string. -- https://bugs.ruby-lang.org/

1 week, 2 days

5
6
0 0

2024

2023

2022

ruby-core March 2024

2024

2023

2022

ruby-core March 2024 ----- 2024 ----- April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023 November 2023 October 2023 September 2023 August 2023 July 2023 June 2023 May 2023 April 2023 March 2023 February 2023 January 2023 ----- 2022 ----- December 2022 November 2022

ruby-core March 2024