[#97086] [Ruby master Bug#16612] Enumerator::ArithmeticSequence#last with float range produces incorrect value — muraken@...
Issue #16612 has been updated by mrkn (Kenta Murata).
4 messages
2020/02/07
[#97307] [Ruby master Feature#16663] Add block or filtered forms of Kernel#caller to allow early bail-out — headius@...
Issue #16663 has been reported by headius (Charles Nutter).
29 messages
2020/02/28
[ruby-core:97206] [Ruby master Bug#16642] Splatted empty hash literal produces frozen hash object
From:
merch-redmine@...
Date:
2020-02-20 00:10:39 UTC
List:
ruby-core #97206
Issue #16642 has been updated by jeremyevans0 (Jeremy Evans).
Actually, looks like I didn't read the bug report closely enough. This is a different issue, and suggests that we should either recognize the frozen hash in the `ruby2_keywords` case and dup it, or remove the optimization.
The issue I was referring to in my last comment is the fact that `{**{}}.frozen?` is true, due to the same optimization.
----------------------------------------
Bug #16642: Splatted empty hash literal produces frozen hash object
https://bugs.ruby-lang.org/issues/16642#change-84314
* Author: Dan0042 (Daniel DeLorme)
* Status: Open
* Priority: Normal
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
When splatting an empty hash literal, internally it's optimized using a global frozen hash object, but this implementation detail can leak into the ruby code outside:
```ruby
ruby2_keywords def foo(*a) a.last end
h = foo(**{})
h[1] = 2
# can't modify frozen Hash: {} (FrozenError)
```
I think this can be considered a bug?
--
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>