(https://github.com/ruby/irb/pull/475)
In the long-term, we want to align with `Pry`, `byebug` and `debug` to
use the `help` command to list all commands, which is what `show_cmds`
currently does. And `show_doc` will be the command to look up Ruby APIs.
By aliasing `show_doc` to the current `help` now, users will have time
to get use to it.
(https://github.com/ruby/irb/pull/473)
* Handle file loading commands' argument error gracefully
Currently, if users don't provide an argument to `source`,
`irb_load`, and `irb_require`, IRB raises `ArgumentError` with full
stacktrace. This is confusing because it looks similar to when IRB has
internal issues. The message also isn't helpful on helping users avoid
the error.
So in this commit, I add a new `CommandArgumentError` for commands to
raise explicitly when users' input doesn't satisfy a command's argument
requirement.
* Gracefully handle `fg` command's argument requirement
Previously, when we froze an object, we froze
`RCLASS_ORIGIN(object.singleton_class)`, which didn't freeze
`object.singleton_class` when it has some prepended modules.
Origin iclass are internal objects and users can't interact with
them through Kernel#freeze?, Kernel#freeze, or any mutation method
that checks the frozen status. So we shouldn't touch the origin
iclasses when the frozen status should be visible.
[Bug #19169]
I see several arguments in doing so.
First they use a non trivial amount of memory, so for various memory
profiling/mapping tools it is relevant to have visibility of the space
occupied by shapes.
Then, some pathological code can create a tons of shape, so it is
valuable to have a way to have a way to observe shapes without having
to compile Ruby with `SHAPE_DEBUG=1`.
And additionally it's likely much faster to dump then this way than
to use `RubyVM::Shape`.
There are however a few open questions:
- Shapes can't respect the `since:` argument. Not sure what to do when
it is provided. Would probably make sense to not dump them.
- Maybe it would make more sense to have a separate `ObjectSpace.dump_shapes`?
- Maybe instead `dump_all` should take a `shapes: false` argument?
Additionally, `ObjectSpace.dump_shapes` is added for the use case of
debugging the evolution of the shape tree.
Unfortunately we have to use a mock, but this test demonstrate the
mutation bug fixed in #19.
It fails on 0.2.0 but passes on 0.1.3 or 0.2.1.
40a1ab687c
This optimization is unsafe because `dest` is allowed to be a custom
object responding to `<<` (e.g. a block wrapped in `ReadAdapter`).
So the receiver can hold onto the passed buffer for as long as it wants.
If it was guaranteed that `ReadAdapter` was the only possible receiver
we could dup the buffer there for mutation safety, but I'm not certain
it's the case so I'd rather err on the safe side.
Ref: https://github.com/shrinerb/shrine/issues/6107efa16d55d
(https://github.com/ruby/irb/pull/472)
* Lazily load the multi-irb extension
We now have plan to implement a command that prints all commands'
information, which will need to load all command files without actually
running them.
But because the `multi-irb` extension patches IRB's top-level methods,
loading it would cause unintentional side-effects.
So this commit moves related requires into command execution to avoid the problem.
* Make extend_irb_context private
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
Cases like this:
```ruby
obj = Object.new
loop do
obj.instance_variable_set(:@foo, 1)
obj.remove_instance_variable(:@foo)
end
```
can cause us to use many more shapes than we want (and even run out).
This commit changes the code such that when an instance variable is
removed, we'll walk up the shape tree, find the shape, then rebuild any
child nodes that happened to be below the "targetted for removal" IV.
This also requires moving any instance variables so that indexes derived
from the shape tree will work correctly.
Co-Authored-By: Jemma Issroff <jemmaissroff@gmail.com>
Co-authored-by: John Hawthorn <jhawthorn@github.com>
