[#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:97205] [Ruby master Bug#16642] Splatted empty hash literal produces frozen hash object
From:
merch-redmine@...
Date:
2020-02-20 00:04:51 UTC
List:
ruby-core #97205
Issue #16642 has been updated by jeremyevans0 (Jeremy Evans).
I agree it is a bug. I'm not sure it is worth fixing. Basically, the reason behind it is the parser doesn't separate hash compilation from keyword argument compilation, and the optimization for `**{}` as the only keyword argument ends up applying to hashes as well. It is simple to remove the optimization, but it will result in worse performance for keyword arguments using `**{}` (which can be used to avoid keyword argument warnings in Ruby 2.7). Separate parsing and/or compilation of keyword arguments and hashes will fix this, and it is on my todo list.
----------------------------------------
Bug #16642: Splatted empty hash literal produces frozen hash object
https://bugs.ruby-lang.org/issues/16642#change-84313
* 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>