[#108771] [Ruby master Bug#18816] Ractor segfaulting MacOS 12.4 (aarch64 / M1 processor) — "brodock (Gabriel Mazetto)" <noreply@...>

Issue #18816 has been reported by brodock (Gabriel Mazetto).

8 messages 2022/06/05

[#108802] [Ruby master Feature#18821] Expose Pattern Matching interfaces in core classes — "baweaver (Brandon Weaver)" <noreply@...>

Issue #18821 has been reported by baweaver (Brandon Weaver).

9 messages 2022/06/08

[#108822] [Ruby master Feature#18822] Ruby lack a proper method to percent-encode strings for URIs (RFC 3986) — "byroot (Jean Boussier)" <noreply@...>

Issue #18822 has been reported by byroot (Jean Boussier).

18 messages 2022/06/09

[#108937] [Ruby master Bug#18832] Suspicious superclass mismatch — "fxn (Xavier Noria)" <noreply@...>

Issue #18832 has been reported by fxn (Xavier Noria).

16 messages 2022/06/15

[#108976] [Ruby master Misc#18836] DevMeeting-2022-07-21 — "mame (Yusuke Endoh)" <noreply@...>

Issue #18836 has been reported by mame (Yusuke Endoh).

12 messages 2022/06/17

[#109043] [Ruby master Bug#18876] OpenSSL is not available with `--with-openssl-dir` — "Gloomy_meng (Gloomy Meng)" <noreply@...>

Issue #18876 has been reported by Gloomy_meng (Gloomy Meng).

18 messages 2022/06/23

[#109052] [Ruby master Bug#18878] parse.y: Foo::Bar {} is inconsistently rejected — "qnighy (Masaki Hara)" <noreply@...>

Issue #18878 has been reported by qnighy (Masaki Hara).

9 messages 2022/06/26

[#109055] [Ruby master Bug#18881] IO#read_nonblock raises IOError when called following buffered character IO — "javanthropus (Jeremy Bopp)" <noreply@...>

Issue #18881 has been reported by javanthropus (Jeremy Bopp).

9 messages 2022/06/26

[#109063] [Ruby master Bug#18882] File.read cuts off a text file with special characters when reading it on MS Windows — magynhard <noreply@...>

Issue #18882 has been reported by magynhard (Matth辰us Johannes Beyrle).

15 messages 2022/06/27

[#109081] [Ruby master Feature#18885] Long lived fork advisory API (potential Copy on Write optimizations) — "byroot (Jean Boussier)" <noreply@...>

Issue #18885 has been reported by byroot (Jean Boussier).

23 messages 2022/06/28

[#109083] [Ruby master Bug#18886] Struct aref and aset don't trigger any tracepoints. — "ioquatix (Samuel Williams)" <noreply@...>

Issue #18886 has been reported by ioquatix (Samuel Williams).

8 messages 2022/06/29

[#109095] [Ruby master Misc#18888] Migrate ruby-lang.org mail services to Google Domains and Google Workspace — "shugo (Shugo Maeda)" <noreply@...>

Issue #18888 has been reported by shugo (Shugo Maeda).

16 messages 2022/06/30

[ruby-core:108905] [Ruby master Bug#18826] Symbol#to_proc inconsistent, sometimes calls private methods

From: "Eregon (Benoit Daloze)" <noreply@...>
Date: 2022-06-14 10:06:35 UTC
List: ruby-core #108905
Issue #18826 has been updated by Eregon (Benoit Daloze).


I think Symbol#to_proc should behave like `public_send`, i.e., only allows calling public methods.
That makes sense given we don't really have a call-site where we can assess the caller self easily, especially if converted to something like `lambda{|t| t.foo}` (i.e., once, in one place, on the `Symbol#to_proc` call, not on every `Proc#call` of that Proc).
This is what TruffleRuby currently implements and it seems to work well and match user expectations (we've only seen one case in Rails which called a protected method, and that code has been replaced already).

So for the protected example:
```ruby
class Array
  protected def foo
    first
  end
end
a = [[1], [2], [3]]
p a.tap(&:foo) # IMHO should be the same as a.tap { |a2| a2.foo } (which is NoMethodError)
p a.collect(&:foo) # IMHO should be the same as a.collect { |o| o.foo } (which is NoMethodError)
```
Semantically, the `self` of the Proc from `Symbol#to_proc`, must be either the `self` at the time `Symbol#to_proc` is called, i.e., the main object here, or a dummy value like `nil` or maybe the Symbol itself (to signify the Proc does not  actually capture the outer scope).
But the `:foo.to_proc.binding.receiver` shouldn't dynamically change when calling that Proc with `Proc#call` (CRuby raises on `:foo.to_proc.binding` but let's think conceptually behind that implementation detail).
The receiver should be fixed for `Symbol#to_proc` procs, just like for every other Proc instance.

So I think the best and most sane (i.e., natural and does not depend on a specific implementation strategy for `Symbol#to_proc`) semantics would be to only allow calling public methods with `Symbol#to_proc`.
If that's deemed too incompatible on CRuby let's at least fix the issue that `Symbol#to_proc` can call private methods sometimes.

----------------------------------------
Bug #18826: Symbol#to_proc inconsistent, sometimes calls private methods
https://bugs.ruby-lang.org/issues/18826#change-97989

* Author: bjfish (Brandon Fish)
* Status: Open
* Priority: Normal
* ruby -v: 3.0.3
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN
----------------------------------------
The following usage calls a protected method and prints "hello":

``` ruby
class Test
    protected

    def referenced_columns
        puts "hello"
    end
end      
Test.new.tap(&:referenced_columns)
```
However, the following usage results in a NoMethodError:

``` ruby
class Integer
    private
    def foo
      42
    end
  end

(1..4).collect(&:foo)

```


It seems to be a bug that tap calls a private method. It is also inconsistent with collect not calling private methods.





-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread