2020-12-25 03:31:48 -05:00
|
|
|
# NEWS for Ruby 3.1.0
|
2020-01-14 22:42:47 -05:00
|
|
|
|
2020-02-16 15:00:34 -05:00
|
|
|
This document is a list of user visible feature changes
|
2020-12-25 03:31:48 -05:00
|
|
|
since the **3.0.0** release, except for bug fixes.
|
2020-01-14 22:42:47 -05:00
|
|
|
|
2020-12-22 14:27:38 -05:00
|
|
|
Note that each entry is kept to a minimum, see links for details.
|
2020-01-14 22:42:47 -05:00
|
|
|
|
2020-01-18 03:46:52 -05:00
|
|
|
## Language changes
|
Evaluate multiple assignment left hand side before right hand side
In regular assignment, Ruby evaluates the left hand side before
the right hand side. For example:
```ruby
foo[0] = bar
```
Calls `foo`, then `bar`, then `[]=` on the result of `foo`.
Previously, multiple assignment didn't work this way. If you did:
```ruby
abc.def, foo[0] = bar, baz
```
Ruby would previously call `bar`, then `baz`, then `abc`, then
`def=` on the result of `abc`, then `foo`, then `[]=` on the
result of `foo`.
This change makes multiple assignment similar to single assignment,
changing the evaluation order of the above multiple assignment code
to calling `abc`, then `foo`, then `bar`, then `baz`, then `def=` on
the result of `abc`, then `[]=` on the result of `foo`.
Implementing this is challenging with the stack-based virtual machine.
We need to keep track of all of the left hand side attribute setter
receivers and setter arguments, and then keep track of the stack level
while handling the assignment processing, so we can issue the
appropriate topn instructions to get the receiver. Here's an example
of how the multiple assignment is executed, showing the stack and
instructions:
```
self # putself
abc # send
abc, self # putself
abc, foo # send
abc, foo, 0 # putobject 0
abc, foo, 0, [bar, baz] # evaluate RHS
abc, foo, 0, [bar, baz], baz, bar # expandarray
abc, foo, 0, [bar, baz], baz, bar, abc # topn 5
abc, foo, 0, [bar, baz], baz, abc, bar # swap
abc, foo, 0, [bar, baz], baz, def= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz], baz, foo # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0 # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0, baz # topn 2
abc, foo, 0, [bar, baz], baz, []= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz] # pop
[bar, baz], foo, 0, [bar, baz] # setn 3
[bar, baz], foo, 0 # pop
[bar, baz], foo # pop
[bar, baz] # pop
```
As multiple assignment must deal with splats, post args, and any level
of nesting, it gets quite a bit more complex than this in non-trivial
cases. To handle this, struct masgn_state is added to keep
track of the overall state of the mass assignment, which stores a linked
list of struct masgn_attrasgn, one for each assigned attribute.
This adds a new optimization that replaces a topn 1/pop instruction
combination with a single swap instruction for multiple assignment
to non-aref attributes.
This new approach isn't compatible with one of the optimizations
previously used, in the case where the multiple assignment return value
was not needed, there was no lhs splat, and one of the left hand side
used an attribute setter. This removes that optimization. Removing
the optimization allowed for removing the POP_ELEMENT and adjust_stack
functions.
This adds a benchmark to measure how much slower multiple
assignment is with the correct evaluation order.
This benchmark shows:
* 4-9% decrease for attribute sets
* 14-23% decrease for array member sets
* Basically same speed for local variable sets
Importantly, it shows no significant difference between the popped
(where return value of the multiple assignment is not needed) and
!popped (where return value of the multiple assignment is needed)
cases for attribute and array member sets. This indicates the
previous optimization, which was dropped in the evaluation
order fix and only affected the popped case, is not important to
performance.
Fixes [Bug #4443]
2021-04-21 13:49:19 -04:00
|
|
|
|
2021-03-21 02:12:54 -04:00
|
|
|
* Pin operator now takes an expression. [[Feature #17411]]
|
|
|
|
|
|
|
|
|
|
```ruby
|
|
|
|
|
Prime.each_cons(2).lazy.find_all{_1 in [n, ^(n + 2)]}.take(3).to_a
|
|
|
|
|
#=> [[3, 5], [5, 7], [11, 13]]
|
|
|
|
|
```
|
2020-01-14 22:42:47 -05:00
|
|
|
|
2021-05-13 18:31:46 -04:00
|
|
|
* Pin operator now supports instance, class, and global variables.
|
2021-07-15 22:23:36 -04:00
|
|
|
[[Feature #17724]]
|
2021-05-13 18:31:46 -04:00
|
|
|
|
2021-07-15 22:23:36 -04:00
|
|
|
```ruby
|
2021-05-13 18:31:46 -04:00
|
|
|
@n = 5
|
|
|
|
|
Prime.each_cons(2).lazy.find{_1 in [n, ^@n]}
|
|
|
|
|
#=> [3, 5]
|
2021-07-15 22:23:36 -04:00
|
|
|
```
|
2021-05-13 18:31:46 -04:00
|
|
|
|
2021-07-16 22:13:52 -04:00
|
|
|
* One-line pattern matching is no longer experimental.
|
|
|
|
|
|
Evaluate multiple assignment left hand side before right hand side
In regular assignment, Ruby evaluates the left hand side before
the right hand side. For example:
```ruby
foo[0] = bar
```
Calls `foo`, then `bar`, then `[]=` on the result of `foo`.
Previously, multiple assignment didn't work this way. If you did:
```ruby
abc.def, foo[0] = bar, baz
```
Ruby would previously call `bar`, then `baz`, then `abc`, then
`def=` on the result of `abc`, then `foo`, then `[]=` on the
result of `foo`.
This change makes multiple assignment similar to single assignment,
changing the evaluation order of the above multiple assignment code
to calling `abc`, then `foo`, then `bar`, then `baz`, then `def=` on
the result of `abc`, then `[]=` on the result of `foo`.
Implementing this is challenging with the stack-based virtual machine.
We need to keep track of all of the left hand side attribute setter
receivers and setter arguments, and then keep track of the stack level
while handling the assignment processing, so we can issue the
appropriate topn instructions to get the receiver. Here's an example
of how the multiple assignment is executed, showing the stack and
instructions:
```
self # putself
abc # send
abc, self # putself
abc, foo # send
abc, foo, 0 # putobject 0
abc, foo, 0, [bar, baz] # evaluate RHS
abc, foo, 0, [bar, baz], baz, bar # expandarray
abc, foo, 0, [bar, baz], baz, bar, abc # topn 5
abc, foo, 0, [bar, baz], baz, abc, bar # swap
abc, foo, 0, [bar, baz], baz, def= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz], baz, foo # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0 # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0, baz # topn 2
abc, foo, 0, [bar, baz], baz, []= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz] # pop
[bar, baz], foo, 0, [bar, baz] # setn 3
[bar, baz], foo, 0 # pop
[bar, baz], foo # pop
[bar, baz] # pop
```
As multiple assignment must deal with splats, post args, and any level
of nesting, it gets quite a bit more complex than this in non-trivial
cases. To handle this, struct masgn_state is added to keep
track of the overall state of the mass assignment, which stores a linked
list of struct masgn_attrasgn, one for each assigned attribute.
This adds a new optimization that replaces a topn 1/pop instruction
combination with a single swap instruction for multiple assignment
to non-aref attributes.
This new approach isn't compatible with one of the optimizations
previously used, in the case where the multiple assignment return value
was not needed, there was no lhs splat, and one of the left hand side
used an attribute setter. This removes that optimization. Removing
the optimization allowed for removing the POP_ELEMENT and adjust_stack
functions.
This adds a benchmark to measure how much slower multiple
assignment is with the correct evaluation order.
This benchmark shows:
* 4-9% decrease for attribute sets
* 14-23% decrease for array member sets
* Basically same speed for local variable sets
Importantly, it shows no significant difference between the popped
(where return value of the multiple assignment is not needed) and
!popped (where return value of the multiple assignment is needed)
cases for attribute and array member sets. This indicates the
previous optimization, which was dropped in the evaluation
order fix and only affected the popped case, is not important to
performance.
Fixes [Bug #4443]
2021-04-21 13:49:19 -04:00
|
|
|
* Multiple assignment evaluation order has been made consistent with
|
|
|
|
|
single assignment evaluation order. With single assignment, Ruby
|
|
|
|
|
uses a left-to-right evaluation order. With this code:
|
|
|
|
|
|
|
|
|
|
```ruby
|
|
|
|
|
foo[0] = bar
|
|
|
|
|
```
|
|
|
|
|
|
2021-09-11 06:18:22 -04:00
|
|
|
The following evaluation order is used:
|
Evaluate multiple assignment left hand side before right hand side
In regular assignment, Ruby evaluates the left hand side before
the right hand side. For example:
```ruby
foo[0] = bar
```
Calls `foo`, then `bar`, then `[]=` on the result of `foo`.
Previously, multiple assignment didn't work this way. If you did:
```ruby
abc.def, foo[0] = bar, baz
```
Ruby would previously call `bar`, then `baz`, then `abc`, then
`def=` on the result of `abc`, then `foo`, then `[]=` on the
result of `foo`.
This change makes multiple assignment similar to single assignment,
changing the evaluation order of the above multiple assignment code
to calling `abc`, then `foo`, then `bar`, then `baz`, then `def=` on
the result of `abc`, then `[]=` on the result of `foo`.
Implementing this is challenging with the stack-based virtual machine.
We need to keep track of all of the left hand side attribute setter
receivers and setter arguments, and then keep track of the stack level
while handling the assignment processing, so we can issue the
appropriate topn instructions to get the receiver. Here's an example
of how the multiple assignment is executed, showing the stack and
instructions:
```
self # putself
abc # send
abc, self # putself
abc, foo # send
abc, foo, 0 # putobject 0
abc, foo, 0, [bar, baz] # evaluate RHS
abc, foo, 0, [bar, baz], baz, bar # expandarray
abc, foo, 0, [bar, baz], baz, bar, abc # topn 5
abc, foo, 0, [bar, baz], baz, abc, bar # swap
abc, foo, 0, [bar, baz], baz, def= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz], baz, foo # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0 # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0, baz # topn 2
abc, foo, 0, [bar, baz], baz, []= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz] # pop
[bar, baz], foo, 0, [bar, baz] # setn 3
[bar, baz], foo, 0 # pop
[bar, baz], foo # pop
[bar, baz] # pop
```
As multiple assignment must deal with splats, post args, and any level
of nesting, it gets quite a bit more complex than this in non-trivial
cases. To handle this, struct masgn_state is added to keep
track of the overall state of the mass assignment, which stores a linked
list of struct masgn_attrasgn, one for each assigned attribute.
This adds a new optimization that replaces a topn 1/pop instruction
combination with a single swap instruction for multiple assignment
to non-aref attributes.
This new approach isn't compatible with one of the optimizations
previously used, in the case where the multiple assignment return value
was not needed, there was no lhs splat, and one of the left hand side
used an attribute setter. This removes that optimization. Removing
the optimization allowed for removing the POP_ELEMENT and adjust_stack
functions.
This adds a benchmark to measure how much slower multiple
assignment is with the correct evaluation order.
This benchmark shows:
* 4-9% decrease for attribute sets
* 14-23% decrease for array member sets
* Basically same speed for local variable sets
Importantly, it shows no significant difference between the popped
(where return value of the multiple assignment is not needed) and
!popped (where return value of the multiple assignment is needed)
cases for attribute and array member sets. This indicates the
previous optimization, which was dropped in the evaluation
order fix and only affected the popped case, is not important to
performance.
Fixes [Bug #4443]
2021-04-21 13:49:19 -04:00
|
|
|
|
2021-09-11 06:18:22 -04:00
|
|
|
1. `foo`
|
|
|
|
|
2. `bar`
|
|
|
|
|
3. `[]=` called on the result of `foo`
|
Evaluate multiple assignment left hand side before right hand side
In regular assignment, Ruby evaluates the left hand side before
the right hand side. For example:
```ruby
foo[0] = bar
```
Calls `foo`, then `bar`, then `[]=` on the result of `foo`.
Previously, multiple assignment didn't work this way. If you did:
```ruby
abc.def, foo[0] = bar, baz
```
Ruby would previously call `bar`, then `baz`, then `abc`, then
`def=` on the result of `abc`, then `foo`, then `[]=` on the
result of `foo`.
This change makes multiple assignment similar to single assignment,
changing the evaluation order of the above multiple assignment code
to calling `abc`, then `foo`, then `bar`, then `baz`, then `def=` on
the result of `abc`, then `[]=` on the result of `foo`.
Implementing this is challenging with the stack-based virtual machine.
We need to keep track of all of the left hand side attribute setter
receivers and setter arguments, and then keep track of the stack level
while handling the assignment processing, so we can issue the
appropriate topn instructions to get the receiver. Here's an example
of how the multiple assignment is executed, showing the stack and
instructions:
```
self # putself
abc # send
abc, self # putself
abc, foo # send
abc, foo, 0 # putobject 0
abc, foo, 0, [bar, baz] # evaluate RHS
abc, foo, 0, [bar, baz], baz, bar # expandarray
abc, foo, 0, [bar, baz], baz, bar, abc # topn 5
abc, foo, 0, [bar, baz], baz, abc, bar # swap
abc, foo, 0, [bar, baz], baz, def= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz], baz, foo # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0 # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0, baz # topn 2
abc, foo, 0, [bar, baz], baz, []= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz] # pop
[bar, baz], foo, 0, [bar, baz] # setn 3
[bar, baz], foo, 0 # pop
[bar, baz], foo # pop
[bar, baz] # pop
```
As multiple assignment must deal with splats, post args, and any level
of nesting, it gets quite a bit more complex than this in non-trivial
cases. To handle this, struct masgn_state is added to keep
track of the overall state of the mass assignment, which stores a linked
list of struct masgn_attrasgn, one for each assigned attribute.
This adds a new optimization that replaces a topn 1/pop instruction
combination with a single swap instruction for multiple assignment
to non-aref attributes.
This new approach isn't compatible with one of the optimizations
previously used, in the case where the multiple assignment return value
was not needed, there was no lhs splat, and one of the left hand side
used an attribute setter. This removes that optimization. Removing
the optimization allowed for removing the POP_ELEMENT and adjust_stack
functions.
This adds a benchmark to measure how much slower multiple
assignment is with the correct evaluation order.
This benchmark shows:
* 4-9% decrease for attribute sets
* 14-23% decrease for array member sets
* Basically same speed for local variable sets
Importantly, it shows no significant difference between the popped
(where return value of the multiple assignment is not needed) and
!popped (where return value of the multiple assignment is needed)
cases for attribute and array member sets. This indicates the
previous optimization, which was dropped in the evaluation
order fix and only affected the popped case, is not important to
performance.
Fixes [Bug #4443]
2021-04-21 13:49:19 -04:00
|
|
|
|
2021-09-11 06:18:22 -04:00
|
|
|
In Ruby before 3.1.0, multiple assignment did not follow this
|
|
|
|
|
evaluation order. With this code:
|
Evaluate multiple assignment left hand side before right hand side
In regular assignment, Ruby evaluates the left hand side before
the right hand side. For example:
```ruby
foo[0] = bar
```
Calls `foo`, then `bar`, then `[]=` on the result of `foo`.
Previously, multiple assignment didn't work this way. If you did:
```ruby
abc.def, foo[0] = bar, baz
```
Ruby would previously call `bar`, then `baz`, then `abc`, then
`def=` on the result of `abc`, then `foo`, then `[]=` on the
result of `foo`.
This change makes multiple assignment similar to single assignment,
changing the evaluation order of the above multiple assignment code
to calling `abc`, then `foo`, then `bar`, then `baz`, then `def=` on
the result of `abc`, then `[]=` on the result of `foo`.
Implementing this is challenging with the stack-based virtual machine.
We need to keep track of all of the left hand side attribute setter
receivers and setter arguments, and then keep track of the stack level
while handling the assignment processing, so we can issue the
appropriate topn instructions to get the receiver. Here's an example
of how the multiple assignment is executed, showing the stack and
instructions:
```
self # putself
abc # send
abc, self # putself
abc, foo # send
abc, foo, 0 # putobject 0
abc, foo, 0, [bar, baz] # evaluate RHS
abc, foo, 0, [bar, baz], baz, bar # expandarray
abc, foo, 0, [bar, baz], baz, bar, abc # topn 5
abc, foo, 0, [bar, baz], baz, abc, bar # swap
abc, foo, 0, [bar, baz], baz, def= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz], baz, foo # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0 # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0, baz # topn 2
abc, foo, 0, [bar, baz], baz, []= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz] # pop
[bar, baz], foo, 0, [bar, baz] # setn 3
[bar, baz], foo, 0 # pop
[bar, baz], foo # pop
[bar, baz] # pop
```
As multiple assignment must deal with splats, post args, and any level
of nesting, it gets quite a bit more complex than this in non-trivial
cases. To handle this, struct masgn_state is added to keep
track of the overall state of the mass assignment, which stores a linked
list of struct masgn_attrasgn, one for each assigned attribute.
This adds a new optimization that replaces a topn 1/pop instruction
combination with a single swap instruction for multiple assignment
to non-aref attributes.
This new approach isn't compatible with one of the optimizations
previously used, in the case where the multiple assignment return value
was not needed, there was no lhs splat, and one of the left hand side
used an attribute setter. This removes that optimization. Removing
the optimization allowed for removing the POP_ELEMENT and adjust_stack
functions.
This adds a benchmark to measure how much slower multiple
assignment is with the correct evaluation order.
This benchmark shows:
* 4-9% decrease for attribute sets
* 14-23% decrease for array member sets
* Basically same speed for local variable sets
Importantly, it shows no significant difference between the popped
(where return value of the multiple assignment is not needed) and
!popped (where return value of the multiple assignment is needed)
cases for attribute and array member sets. This indicates the
previous optimization, which was dropped in the evaluation
order fix and only affected the popped case, is not important to
performance.
Fixes [Bug #4443]
2021-04-21 13:49:19 -04:00
|
|
|
|
2021-09-11 06:18:22 -04:00
|
|
|
```ruby
|
|
|
|
|
foo[0], bar.baz = a, b
|
|
|
|
|
```
|
Evaluate multiple assignment left hand side before right hand side
In regular assignment, Ruby evaluates the left hand side before
the right hand side. For example:
```ruby
foo[0] = bar
```
Calls `foo`, then `bar`, then `[]=` on the result of `foo`.
Previously, multiple assignment didn't work this way. If you did:
```ruby
abc.def, foo[0] = bar, baz
```
Ruby would previously call `bar`, then `baz`, then `abc`, then
`def=` on the result of `abc`, then `foo`, then `[]=` on the
result of `foo`.
This change makes multiple assignment similar to single assignment,
changing the evaluation order of the above multiple assignment code
to calling `abc`, then `foo`, then `bar`, then `baz`, then `def=` on
the result of `abc`, then `[]=` on the result of `foo`.
Implementing this is challenging with the stack-based virtual machine.
We need to keep track of all of the left hand side attribute setter
receivers and setter arguments, and then keep track of the stack level
while handling the assignment processing, so we can issue the
appropriate topn instructions to get the receiver. Here's an example
of how the multiple assignment is executed, showing the stack and
instructions:
```
self # putself
abc # send
abc, self # putself
abc, foo # send
abc, foo, 0 # putobject 0
abc, foo, 0, [bar, baz] # evaluate RHS
abc, foo, 0, [bar, baz], baz, bar # expandarray
abc, foo, 0, [bar, baz], baz, bar, abc # topn 5
abc, foo, 0, [bar, baz], baz, abc, bar # swap
abc, foo, 0, [bar, baz], baz, def= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz], baz, foo # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0 # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0, baz # topn 2
abc, foo, 0, [bar, baz], baz, []= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz] # pop
[bar, baz], foo, 0, [bar, baz] # setn 3
[bar, baz], foo, 0 # pop
[bar, baz], foo # pop
[bar, baz] # pop
```
As multiple assignment must deal with splats, post args, and any level
of nesting, it gets quite a bit more complex than this in non-trivial
cases. To handle this, struct masgn_state is added to keep
track of the overall state of the mass assignment, which stores a linked
list of struct masgn_attrasgn, one for each assigned attribute.
This adds a new optimization that replaces a topn 1/pop instruction
combination with a single swap instruction for multiple assignment
to non-aref attributes.
This new approach isn't compatible with one of the optimizations
previously used, in the case where the multiple assignment return value
was not needed, there was no lhs splat, and one of the left hand side
used an attribute setter. This removes that optimization. Removing
the optimization allowed for removing the POP_ELEMENT and adjust_stack
functions.
This adds a benchmark to measure how much slower multiple
assignment is with the correct evaluation order.
This benchmark shows:
* 4-9% decrease for attribute sets
* 14-23% decrease for array member sets
* Basically same speed for local variable sets
Importantly, it shows no significant difference between the popped
(where return value of the multiple assignment is not needed) and
!popped (where return value of the multiple assignment is needed)
cases for attribute and array member sets. This indicates the
previous optimization, which was dropped in the evaluation
order fix and only affected the popped case, is not important to
performance.
Fixes [Bug #4443]
2021-04-21 13:49:19 -04:00
|
|
|
|
2021-09-11 06:18:22 -04:00
|
|
|
Versions of Ruby before 3.1.0 would evaluate in the following
|
|
|
|
|
order
|
Evaluate multiple assignment left hand side before right hand side
In regular assignment, Ruby evaluates the left hand side before
the right hand side. For example:
```ruby
foo[0] = bar
```
Calls `foo`, then `bar`, then `[]=` on the result of `foo`.
Previously, multiple assignment didn't work this way. If you did:
```ruby
abc.def, foo[0] = bar, baz
```
Ruby would previously call `bar`, then `baz`, then `abc`, then
`def=` on the result of `abc`, then `foo`, then `[]=` on the
result of `foo`.
This change makes multiple assignment similar to single assignment,
changing the evaluation order of the above multiple assignment code
to calling `abc`, then `foo`, then `bar`, then `baz`, then `def=` on
the result of `abc`, then `[]=` on the result of `foo`.
Implementing this is challenging with the stack-based virtual machine.
We need to keep track of all of the left hand side attribute setter
receivers and setter arguments, and then keep track of the stack level
while handling the assignment processing, so we can issue the
appropriate topn instructions to get the receiver. Here's an example
of how the multiple assignment is executed, showing the stack and
instructions:
```
self # putself
abc # send
abc, self # putself
abc, foo # send
abc, foo, 0 # putobject 0
abc, foo, 0, [bar, baz] # evaluate RHS
abc, foo, 0, [bar, baz], baz, bar # expandarray
abc, foo, 0, [bar, baz], baz, bar, abc # topn 5
abc, foo, 0, [bar, baz], baz, abc, bar # swap
abc, foo, 0, [bar, baz], baz, def= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz], baz, foo # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0 # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0, baz # topn 2
abc, foo, 0, [bar, baz], baz, []= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz] # pop
[bar, baz], foo, 0, [bar, baz] # setn 3
[bar, baz], foo, 0 # pop
[bar, baz], foo # pop
[bar, baz] # pop
```
As multiple assignment must deal with splats, post args, and any level
of nesting, it gets quite a bit more complex than this in non-trivial
cases. To handle this, struct masgn_state is added to keep
track of the overall state of the mass assignment, which stores a linked
list of struct masgn_attrasgn, one for each assigned attribute.
This adds a new optimization that replaces a topn 1/pop instruction
combination with a single swap instruction for multiple assignment
to non-aref attributes.
This new approach isn't compatible with one of the optimizations
previously used, in the case where the multiple assignment return value
was not needed, there was no lhs splat, and one of the left hand side
used an attribute setter. This removes that optimization. Removing
the optimization allowed for removing the POP_ELEMENT and adjust_stack
functions.
This adds a benchmark to measure how much slower multiple
assignment is with the correct evaluation order.
This benchmark shows:
* 4-9% decrease for attribute sets
* 14-23% decrease for array member sets
* Basically same speed for local variable sets
Importantly, it shows no significant difference between the popped
(where return value of the multiple assignment is not needed) and
!popped (where return value of the multiple assignment is needed)
cases for attribute and array member sets. This indicates the
previous optimization, which was dropped in the evaluation
order fix and only affected the popped case, is not important to
performance.
Fixes [Bug #4443]
2021-04-21 13:49:19 -04:00
|
|
|
|
2021-09-11 06:18:22 -04:00
|
|
|
1. `a`
|
|
|
|
|
2. `b`
|
|
|
|
|
3. `foo`
|
|
|
|
|
4. `[]=` called on the result of `foo`
|
|
|
|
|
5. `bar`
|
|
|
|
|
6. `baz=` called on the result of `bar`
|
Evaluate multiple assignment left hand side before right hand side
In regular assignment, Ruby evaluates the left hand side before
the right hand side. For example:
```ruby
foo[0] = bar
```
Calls `foo`, then `bar`, then `[]=` on the result of `foo`.
Previously, multiple assignment didn't work this way. If you did:
```ruby
abc.def, foo[0] = bar, baz
```
Ruby would previously call `bar`, then `baz`, then `abc`, then
`def=` on the result of `abc`, then `foo`, then `[]=` on the
result of `foo`.
This change makes multiple assignment similar to single assignment,
changing the evaluation order of the above multiple assignment code
to calling `abc`, then `foo`, then `bar`, then `baz`, then `def=` on
the result of `abc`, then `[]=` on the result of `foo`.
Implementing this is challenging with the stack-based virtual machine.
We need to keep track of all of the left hand side attribute setter
receivers and setter arguments, and then keep track of the stack level
while handling the assignment processing, so we can issue the
appropriate topn instructions to get the receiver. Here's an example
of how the multiple assignment is executed, showing the stack and
instructions:
```
self # putself
abc # send
abc, self # putself
abc, foo # send
abc, foo, 0 # putobject 0
abc, foo, 0, [bar, baz] # evaluate RHS
abc, foo, 0, [bar, baz], baz, bar # expandarray
abc, foo, 0, [bar, baz], baz, bar, abc # topn 5
abc, foo, 0, [bar, baz], baz, abc, bar # swap
abc, foo, 0, [bar, baz], baz, def= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz], baz, foo # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0 # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0, baz # topn 2
abc, foo, 0, [bar, baz], baz, []= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz] # pop
[bar, baz], foo, 0, [bar, baz] # setn 3
[bar, baz], foo, 0 # pop
[bar, baz], foo # pop
[bar, baz] # pop
```
As multiple assignment must deal with splats, post args, and any level
of nesting, it gets quite a bit more complex than this in non-trivial
cases. To handle this, struct masgn_state is added to keep
track of the overall state of the mass assignment, which stores a linked
list of struct masgn_attrasgn, one for each assigned attribute.
This adds a new optimization that replaces a topn 1/pop instruction
combination with a single swap instruction for multiple assignment
to non-aref attributes.
This new approach isn't compatible with one of the optimizations
previously used, in the case where the multiple assignment return value
was not needed, there was no lhs splat, and one of the left hand side
used an attribute setter. This removes that optimization. Removing
the optimization allowed for removing the POP_ELEMENT and adjust_stack
functions.
This adds a benchmark to measure how much slower multiple
assignment is with the correct evaluation order.
This benchmark shows:
* 4-9% decrease for attribute sets
* 14-23% decrease for array member sets
* Basically same speed for local variable sets
Importantly, it shows no significant difference between the popped
(where return value of the multiple assignment is not needed) and
!popped (where return value of the multiple assignment is needed)
cases for attribute and array member sets. This indicates the
previous optimization, which was dropped in the evaluation
order fix and only affected the popped case, is not important to
performance.
Fixes [Bug #4443]
2021-04-21 13:49:19 -04:00
|
|
|
|
2021-09-11 06:18:22 -04:00
|
|
|
Starting in Ruby 3.1.0, evaluation order is now consistent with
|
|
|
|
|
single assignment, with the left hand side being evaluated before
|
|
|
|
|
the right hand side:
|
Evaluate multiple assignment left hand side before right hand side
In regular assignment, Ruby evaluates the left hand side before
the right hand side. For example:
```ruby
foo[0] = bar
```
Calls `foo`, then `bar`, then `[]=` on the result of `foo`.
Previously, multiple assignment didn't work this way. If you did:
```ruby
abc.def, foo[0] = bar, baz
```
Ruby would previously call `bar`, then `baz`, then `abc`, then
`def=` on the result of `abc`, then `foo`, then `[]=` on the
result of `foo`.
This change makes multiple assignment similar to single assignment,
changing the evaluation order of the above multiple assignment code
to calling `abc`, then `foo`, then `bar`, then `baz`, then `def=` on
the result of `abc`, then `[]=` on the result of `foo`.
Implementing this is challenging with the stack-based virtual machine.
We need to keep track of all of the left hand side attribute setter
receivers and setter arguments, and then keep track of the stack level
while handling the assignment processing, so we can issue the
appropriate topn instructions to get the receiver. Here's an example
of how the multiple assignment is executed, showing the stack and
instructions:
```
self # putself
abc # send
abc, self # putself
abc, foo # send
abc, foo, 0 # putobject 0
abc, foo, 0, [bar, baz] # evaluate RHS
abc, foo, 0, [bar, baz], baz, bar # expandarray
abc, foo, 0, [bar, baz], baz, bar, abc # topn 5
abc, foo, 0, [bar, baz], baz, abc, bar # swap
abc, foo, 0, [bar, baz], baz, def= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz], baz, foo # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0 # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0, baz # topn 2
abc, foo, 0, [bar, baz], baz, []= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz] # pop
[bar, baz], foo, 0, [bar, baz] # setn 3
[bar, baz], foo, 0 # pop
[bar, baz], foo # pop
[bar, baz] # pop
```
As multiple assignment must deal with splats, post args, and any level
of nesting, it gets quite a bit more complex than this in non-trivial
cases. To handle this, struct masgn_state is added to keep
track of the overall state of the mass assignment, which stores a linked
list of struct masgn_attrasgn, one for each assigned attribute.
This adds a new optimization that replaces a topn 1/pop instruction
combination with a single swap instruction for multiple assignment
to non-aref attributes.
This new approach isn't compatible with one of the optimizations
previously used, in the case where the multiple assignment return value
was not needed, there was no lhs splat, and one of the left hand side
used an attribute setter. This removes that optimization. Removing
the optimization allowed for removing the POP_ELEMENT and adjust_stack
functions.
This adds a benchmark to measure how much slower multiple
assignment is with the correct evaluation order.
This benchmark shows:
* 4-9% decrease for attribute sets
* 14-23% decrease for array member sets
* Basically same speed for local variable sets
Importantly, it shows no significant difference between the popped
(where return value of the multiple assignment is not needed) and
!popped (where return value of the multiple assignment is needed)
cases for attribute and array member sets. This indicates the
previous optimization, which was dropped in the evaluation
order fix and only affected the popped case, is not important to
performance.
Fixes [Bug #4443]
2021-04-21 13:49:19 -04:00
|
|
|
|
2021-09-11 06:18:22 -04:00
|
|
|
1. `foo`
|
|
|
|
|
2. `bar`
|
|
|
|
|
3. `a`
|
|
|
|
|
4. `b`
|
|
|
|
|
5. `[]=` called on the result of `foo`
|
|
|
|
|
6. `baz=` called on the result of `bar`
|
Evaluate multiple assignment left hand side before right hand side
In regular assignment, Ruby evaluates the left hand side before
the right hand side. For example:
```ruby
foo[0] = bar
```
Calls `foo`, then `bar`, then `[]=` on the result of `foo`.
Previously, multiple assignment didn't work this way. If you did:
```ruby
abc.def, foo[0] = bar, baz
```
Ruby would previously call `bar`, then `baz`, then `abc`, then
`def=` on the result of `abc`, then `foo`, then `[]=` on the
result of `foo`.
This change makes multiple assignment similar to single assignment,
changing the evaluation order of the above multiple assignment code
to calling `abc`, then `foo`, then `bar`, then `baz`, then `def=` on
the result of `abc`, then `[]=` on the result of `foo`.
Implementing this is challenging with the stack-based virtual machine.
We need to keep track of all of the left hand side attribute setter
receivers and setter arguments, and then keep track of the stack level
while handling the assignment processing, so we can issue the
appropriate topn instructions to get the receiver. Here's an example
of how the multiple assignment is executed, showing the stack and
instructions:
```
self # putself
abc # send
abc, self # putself
abc, foo # send
abc, foo, 0 # putobject 0
abc, foo, 0, [bar, baz] # evaluate RHS
abc, foo, 0, [bar, baz], baz, bar # expandarray
abc, foo, 0, [bar, baz], baz, bar, abc # topn 5
abc, foo, 0, [bar, baz], baz, abc, bar # swap
abc, foo, 0, [bar, baz], baz, def= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz], baz, foo # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0 # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0, baz # topn 2
abc, foo, 0, [bar, baz], baz, []= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz] # pop
[bar, baz], foo, 0, [bar, baz] # setn 3
[bar, baz], foo, 0 # pop
[bar, baz], foo # pop
[bar, baz] # pop
```
As multiple assignment must deal with splats, post args, and any level
of nesting, it gets quite a bit more complex than this in non-trivial
cases. To handle this, struct masgn_state is added to keep
track of the overall state of the mass assignment, which stores a linked
list of struct masgn_attrasgn, one for each assigned attribute.
This adds a new optimization that replaces a topn 1/pop instruction
combination with a single swap instruction for multiple assignment
to non-aref attributes.
This new approach isn't compatible with one of the optimizations
previously used, in the case where the multiple assignment return value
was not needed, there was no lhs splat, and one of the left hand side
used an attribute setter. This removes that optimization. Removing
the optimization allowed for removing the POP_ELEMENT and adjust_stack
functions.
This adds a benchmark to measure how much slower multiple
assignment is with the correct evaluation order.
This benchmark shows:
* 4-9% decrease for attribute sets
* 14-23% decrease for array member sets
* Basically same speed for local variable sets
Importantly, it shows no significant difference between the popped
(where return value of the multiple assignment is not needed) and
!popped (where return value of the multiple assignment is needed)
cases for attribute and array member sets. This indicates the
previous optimization, which was dropped in the evaluation
order fix and only affected the popped case, is not important to
performance.
Fixes [Bug #4443]
2021-04-21 13:49:19 -04:00
|
|
|
|
2021-09-11 06:18:22 -04:00
|
|
|
[[Bug #4443]]
|
Evaluate multiple assignment left hand side before right hand side
In regular assignment, Ruby evaluates the left hand side before
the right hand side. For example:
```ruby
foo[0] = bar
```
Calls `foo`, then `bar`, then `[]=` on the result of `foo`.
Previously, multiple assignment didn't work this way. If you did:
```ruby
abc.def, foo[0] = bar, baz
```
Ruby would previously call `bar`, then `baz`, then `abc`, then
`def=` on the result of `abc`, then `foo`, then `[]=` on the
result of `foo`.
This change makes multiple assignment similar to single assignment,
changing the evaluation order of the above multiple assignment code
to calling `abc`, then `foo`, then `bar`, then `baz`, then `def=` on
the result of `abc`, then `[]=` on the result of `foo`.
Implementing this is challenging with the stack-based virtual machine.
We need to keep track of all of the left hand side attribute setter
receivers and setter arguments, and then keep track of the stack level
while handling the assignment processing, so we can issue the
appropriate topn instructions to get the receiver. Here's an example
of how the multiple assignment is executed, showing the stack and
instructions:
```
self # putself
abc # send
abc, self # putself
abc, foo # send
abc, foo, 0 # putobject 0
abc, foo, 0, [bar, baz] # evaluate RHS
abc, foo, 0, [bar, baz], baz, bar # expandarray
abc, foo, 0, [bar, baz], baz, bar, abc # topn 5
abc, foo, 0, [bar, baz], baz, abc, bar # swap
abc, foo, 0, [bar, baz], baz, def= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz], baz, foo # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0 # topn 3
abc, foo, 0, [bar, baz], baz, foo, 0, baz # topn 2
abc, foo, 0, [bar, baz], baz, []= # send
abc, foo, 0, [bar, baz], baz # pop
abc, foo, 0, [bar, baz] # pop
[bar, baz], foo, 0, [bar, baz] # setn 3
[bar, baz], foo, 0 # pop
[bar, baz], foo # pop
[bar, baz] # pop
```
As multiple assignment must deal with splats, post args, and any level
of nesting, it gets quite a bit more complex than this in non-trivial
cases. To handle this, struct masgn_state is added to keep
track of the overall state of the mass assignment, which stores a linked
list of struct masgn_attrasgn, one for each assigned attribute.
This adds a new optimization that replaces a topn 1/pop instruction
combination with a single swap instruction for multiple assignment
to non-aref attributes.
This new approach isn't compatible with one of the optimizations
previously used, in the case where the multiple assignment return value
was not needed, there was no lhs splat, and one of the left hand side
used an attribute setter. This removes that optimization. Removing
the optimization allowed for removing the POP_ELEMENT and adjust_stack
functions.
This adds a benchmark to measure how much slower multiple
assignment is with the correct evaluation order.
This benchmark shows:
* 4-9% decrease for attribute sets
* 14-23% decrease for array member sets
* Basically same speed for local variable sets
Importantly, it shows no significant difference between the popped
(where return value of the multiple assignment is not needed) and
!popped (where return value of the multiple assignment is needed)
cases for attribute and array member sets. This indicates the
previous optimization, which was dropped in the evaluation
order fix and only affected the popped case, is not important to
performance.
Fixes [Bug #4443]
2021-04-21 13:49:19 -04:00
|
|
|
|
2020-01-18 03:46:52 -05:00
|
|
|
## Command line options
|
2020-01-14 22:42:47 -05:00
|
|
|
|
2020-03-03 03:37:51 -05:00
|
|
|
## Core classes updates
|
|
|
|
|
|
|
|
|
|
Outstanding ones only.
|
2020-01-14 22:42:47 -05:00
|
|
|
|
2021-04-16 03:12:10 -04:00
|
|
|
* Array
|
|
|
|
|
|
|
|
|
|
* Array#intersect? is added. [[Feature #15198]]
|
|
|
|
|
|
2021-01-02 02:42:45 -05:00
|
|
|
* Enumerable
|
|
|
|
|
|
|
|
|
|
* Enumerable#compact is added. [[Feature #17312]]
|
|
|
|
|
|
2021-03-26 03:29:21 -04:00
|
|
|
* Enumerable#tally now accepts an optional hash to count. [[Feature #17744]]
|
|
|
|
|
|
2021-01-02 02:42:45 -05:00
|
|
|
* Enumerator::Lazy
|
|
|
|
|
|
|
|
|
|
* Enumerator::Lazy#compact is added. [[Feature #17312]]
|
|
|
|
|
|
2021-03-15 07:05:03 -04:00
|
|
|
* File
|
|
|
|
|
|
|
|
|
|
* File.dirname now accepts an optional argument for the level to
|
|
|
|
|
strip path components. [[Feature #12194]]
|
|
|
|
|
|
2018-10-07 00:02:46 -04:00
|
|
|
* Integer
|
|
|
|
|
|
|
|
|
|
* Integer.try_convert is added. [[Feature #15211]]
|
|
|
|
|
|
2021-01-14 14:59:25 -05:00
|
|
|
* Module
|
|
|
|
|
|
|
|
|
|
* Module#prepend now modifies the ancestor chain if the receiver
|
|
|
|
|
already includes the argument. Module#prepend still does not
|
|
|
|
|
modify the ancestor chain if the receiver has already prepended
|
|
|
|
|
the argument. [[Bug #17423]]
|
|
|
|
|
|
2021-01-17 04:35:54 -05:00
|
|
|
* Struct
|
|
|
|
|
|
|
|
|
|
* Passing only keyword arguments to Struct#initialize is warned.
|
|
|
|
|
You need to use a Hash literal to set a Hash to a first member.
|
|
|
|
|
[[Feature #16806]]
|
|
|
|
|
|
2021-07-15 05:21:49 -04:00
|
|
|
* StructClass#keyword_init? is added [[Feature #18008]]
|
|
|
|
|
|
2021-08-17 04:07:01 -04:00
|
|
|
* String
|
|
|
|
|
|
|
|
|
|
* Update Unicode version to 13.0.0 [[Feature #17750]]
|
|
|
|
|
and Emoji version to 13.0 [[Feature #18029]]
|
|
|
|
|
|
2021-02-11 05:14:18 -05:00
|
|
|
* Queue
|
|
|
|
|
|
|
|
|
|
* Queue#initialize now accepts an Enumerable of initial values.
|
|
|
|
|
[[Feature #17327]]
|
|
|
|
|
|
2021-05-26 02:18:16 -04:00
|
|
|
* Thread
|
|
|
|
|
|
|
|
|
|
* Thread#native_thread_id is added. [[Feature #17853]]
|
|
|
|
|
|
2021-02-15 02:06:43 -05:00
|
|
|
* Thread::Backtrace
|
|
|
|
|
|
|
|
|
|
* Thread::Backtrace.limit, which returns the value to limit backtrace
|
2021-07-15 02:38:39 -04:00
|
|
|
length set by `--backtrace-limit` command line option, is added.
|
2021-02-15 02:06:43 -05:00
|
|
|
[[Feature #17479]]
|
|
|
|
|
|
2021-02-16 04:12:47 -05:00
|
|
|
* $LOAD_PATH
|
|
|
|
|
|
|
|
|
|
* $LOAD_PATH.resolve_feature_path does not raise. [[Feature #16043]]
|
|
|
|
|
|
2021-06-22 07:14:45 -04:00
|
|
|
* Fiber Scheduler
|
|
|
|
|
|
|
|
|
|
* Add support for `Addrinfo.getaddrinfo` using `address_resolve` hook.
|
|
|
|
|
[[Feature #17370]]
|
|
|
|
|
|
|
|
|
|
* Introduce non-blocking `Timeout.timeout` using `timeout_after` hook.
|
|
|
|
|
[[Feature #17470]]
|
|
|
|
|
|
|
|
|
|
* IO hooks `io_wait`, `io_read`, `io_write`, receive the original IO object
|
|
|
|
|
where possible. [[Bug #18003]]
|
|
|
|
|
|
2021-06-22 07:18:40 -04:00
|
|
|
* Make `Monitor` fiber-safe. [[Bug #17827]]
|
2021-06-22 07:14:45 -04:00
|
|
|
|
2021-06-25 18:17:26 -04:00
|
|
|
* Replace copy coroutine with pthread implementation. [[Feature #18015]]
|
|
|
|
|
|
2020-03-03 03:37:51 -05:00
|
|
|
## Stdlib updates
|
|
|
|
|
|
|
|
|
|
Outstanding ones only.
|
2020-01-14 22:42:47 -05:00
|
|
|
|
2020-03-03 03:37:51 -05:00
|
|
|
## Compatibility issues
|
|
|
|
|
|
|
|
|
|
Excluding feature bug fixes.
|
2020-01-14 22:42:47 -05:00
|
|
|
|
2021-06-22 07:14:45 -04:00
|
|
|
* `rb_io_wait_readable`, `rb_io_wait_writable` and `rb_wait_for_single_fd` are
|
|
|
|
|
deprecated in favour of `rb_io_maybe_wait_readable`,
|
|
|
|
|
`rb_io_maybe_wait_writable` and `rb_io_maybe_wait` respectively.
|
|
|
|
|
`rb_thread_wait_fd` and `rb_thread_fd_writable` are deprecated. [[Bug #18003]]
|
|
|
|
|
|
2020-08-24 02:38:03 -04:00
|
|
|
## Stdlib compatibility issues
|
2020-06-18 08:11:19 -04:00
|
|
|
|
2021-01-21 01:02:24 -05:00
|
|
|
* `ERB#initialize` warns `safe_level` and later arguments even without -w.
|
|
|
|
|
[[Feature #14256]]
|
|
|
|
|
|
2020-01-18 03:46:52 -05:00
|
|
|
## C API updates
|
2020-01-14 22:42:47 -05:00
|
|
|
|
2020-01-18 03:46:52 -05:00
|
|
|
## Implementation improvements
|
2020-01-14 22:42:47 -05:00
|
|
|
|
2020-06-26 03:54:05 -04:00
|
|
|
### JIT
|
|
|
|
|
|
2021-06-01 01:00:14 -04:00
|
|
|
* The default `--jit-max-cache` is changed from 100 to 10000.
|
|
|
|
|
|
2021-08-13 02:19:15 -04:00
|
|
|
* JIT-ed code is no longer cancelled when a TracePoint for class events
|
|
|
|
|
is enabled.
|
|
|
|
|
|
2021-06-03 01:25:48 -04:00
|
|
|
* The JIT compiler no longer skips compilation of methods longer than
|
|
|
|
|
1000 instructions.
|
|
|
|
|
|
2021-08-13 01:54:40 -04:00
|
|
|
* `--jit-verbose` and `--jit-warning` output "JIT cancel" when JIT-ed
|
|
|
|
|
code is disabled because TracePoint or GC.compact is used.
|
|
|
|
|
|
2021-06-01 01:00:14 -04:00
|
|
|
* `RubyVM::MJIT` is renamed to `RubyVM::JIT`. [[Feature #17490]]
|
2021-01-14 01:36:45 -05:00
|
|
|
|
2020-11-10 12:15:57 -05:00
|
|
|
## Static analysis
|
2020-10-20 00:16:19 -04:00
|
|
|
|
|
|
|
|
### RBS
|
2020-09-25 04:08:39 -04:00
|
|
|
|
2020-10-20 00:16:19 -04:00
|
|
|
### TypeProf
|
|
|
|
|
|
2020-01-18 03:46:52 -05:00
|
|
|
## Miscellaneous changes
|
2021-01-02 02:42:45 -05:00
|
|
|
|
2021-05-16 19:49:53 -04:00
|
|
|
* lib/objspace/trace.rb is added, which is a tool for tracing the object
|
|
|
|
|
allocation. Just by requiring this file, tracing is started *immediately*.
|
|
|
|
|
Just by `Kernel#p`, you can investigate where an object was created.
|
|
|
|
|
Note that just requiring this file brings a large performance overhead.
|
|
|
|
|
This is only for debugging purpose. Do not use this in production.
|
2021-07-22 23:41:01 -04:00
|
|
|
[[Feature #17762]]
|
2021-01-02 02:42:45 -05:00
|
|
|
|
2021-07-22 23:41:34 -04:00
|
|
|
* Now exceptions raised in finalizers will be printed to `STDERR`, unless
|
|
|
|
|
`$VERBOSE` is `nil`. [[Feature #17798]]
|
|
|
|
|
|
2021-07-22 23:41:01 -04:00
|
|
|
[Bug #4443]: https://bugs.ruby-lang.org/issues/4443
|
2021-03-16 01:07:27 -04:00
|
|
|
[Feature #12194]: https://bugs.ruby-lang.org/issues/12194
|
2021-01-21 01:02:24 -05:00
|
|
|
[Feature #14256]: https://bugs.ruby-lang.org/issues/14256
|
2021-04-16 03:12:10 -04:00
|
|
|
[Feature #15198]: https://bugs.ruby-lang.org/issues/15198
|
2018-10-07 00:02:46 -04:00
|
|
|
[Feature #15211]: https://bugs.ruby-lang.org/issues/15211
|
2021-02-16 04:12:47 -05:00
|
|
|
[Feature #16043]: https://bugs.ruby-lang.org/issues/16043
|
2021-01-17 04:35:54 -05:00
|
|
|
[Feature #16806]: https://bugs.ruby-lang.org/issues/16806
|
2021-01-02 02:42:45 -05:00
|
|
|
[Feature #17312]: https://bugs.ruby-lang.org/issues/17312
|
2021-02-11 05:14:18 -05:00
|
|
|
[Feature #17327]: https://bugs.ruby-lang.org/issues/17327
|
2021-03-21 02:12:54 -04:00
|
|
|
[Feature #17411]: https://bugs.ruby-lang.org/issues/17411
|
2021-07-22 23:41:01 -04:00
|
|
|
[Bug #17423]: https://bugs.ruby-lang.org/issues/17423
|
2021-02-15 02:06:43 -05:00
|
|
|
[Feature #17479]: https://bugs.ruby-lang.org/issues/17479
|
2021-06-01 01:00:14 -04:00
|
|
|
[Feature #17490]: https://bugs.ruby-lang.org/issues/17490
|
2021-05-13 18:31:46 -04:00
|
|
|
[Feature #17724]: https://bugs.ruby-lang.org/issues/17724
|
2021-03-26 03:29:21 -04:00
|
|
|
[Feature #17744]: https://bugs.ruby-lang.org/issues/17744
|
2021-05-16 19:49:53 -04:00
|
|
|
[Feature #17762]: https://bugs.ruby-lang.org/issues/17762
|
2021-07-22 23:41:34 -04:00
|
|
|
[Feature #17798]: https://bugs.ruby-lang.org/issues/17798
|
2021-07-22 23:41:01 -04:00
|
|
|
[Bug #18003]: https://bugs.ruby-lang.org/issues/18003
|
2021-06-22 07:14:45 -04:00
|
|
|
[Feature #17370]: https://bugs.ruby-lang.org/issues/17370
|
|
|
|
|
[Feature #17470]: https://bugs.ruby-lang.org/issues/17470
|
2021-08-22 09:27:29 -04:00
|
|
|
[Feature #17750]: https://bugs.ruby-lang.org/issues/17750
|
2021-06-22 20:23:54 -04:00
|
|
|
[Feature #17853]: https://bugs.ruby-lang.org/issues/17853
|
2021-07-22 23:41:01 -04:00
|
|
|
[Bug #17827]: https://bugs.ruby-lang.org/issues/17827
|
2021-08-05 04:25:17 -04:00
|
|
|
[Feature #18008]: https://bugs.ruby-lang.org/issues/18008
|
2021-06-25 18:17:26 -04:00
|
|
|
[Feature #18015]: https://bugs.ruby-lang.org/issues/18015
|
2021-08-22 09:27:29 -04:00
|
|
|
[Feature #18029]: https://bugs.ruby-lang.org/issues/18029
|