| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Pick from https://github.com/ruby/syntax_suggest/commit/daee74dcb06296fa69fe8595fdff5d93d432b30d
|
| |
|
| |
|
|
|
|
| |
Pick from https://github.com/rubygems/rubygems/commit/823c776d951f3c35094611473ec77f94e8bf6610
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
66d1900423e6fb9774c2fe72dba8c2968b54d7ab
0686e4181d04dd911316a227753ceaa96d8c6533
1a63468831524f68e73cbb068071652c6486cfc6
e1fee7f949cb6719122672fa1081c60984a5339f
232e43fd52e53f667c2c290cffb4afa524889f0f
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
I'm gonna add another type of unit shortly.
|
|
|
|
| |
There's no MJIT worker thread anymore
|
| |
|
|
|
|
| |
https://github.com/ruby/rdoc/commit/e1679fa7e4
|
|
|
|
| |
https://github.com/ruby/rdoc/commit/fe0159de2f
|
|
|
|
| |
https://github.com/ruby/rdoc/commit/0b9dde5ab4
|
|
|
|
| |
https://github.com/ruby/erb/commit/39414f32a5
|
| |
|
|
|
|
| |
https://github.com/ruby/etc/commit/5cac138538
|
| |
|
| |
|
|
|
|
| |
https://github.com/ruby/irb/commit/d799c5c9da
|
| |
|
|
|
|
|
|
|
|
|
| |
The new version has an option to merge everything into a big
`extern "C"` block and it's nicer.
More importantly, this upgrade fixes an issue where Ubuntu with Clang 12
and macOS with Clang 14 gave a one line diff for `rb_shape_t`. It was
slightly annoying because we use macOS locally.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(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
|
| |
|
|
|
|
| |
https://github.com/ruby/stringio/commit/e62b9d78d3
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
|
|
|
|
| |
So it's shorter on CI and the hint about how the fix the failure shows
up. It's going to print a diff locally too, but that should be fine.
|
|
|
|
|
|
| |
This makes it clear what to do when the CI check
fails and should remove a few minutes of confusion
for people seeing this for the first time.
|
|
|
|
|
|
|
| |
(https://github.com/ruby/irb/pull/471)
The killing/waiting logic is borrowed from ruby/debug:
https://github.com/ruby/debug/blob/ec5ae5aebd61a99dc84028d8dffa8e7e165c1ec6/test/support/test_case.rb#L107-L136
|
|
|
|
|
|
|
| |
descriptions
(https://github.com/ruby/irb/pull/463)
https://github.com/ruby/irb/commit/7e857655ac
|
|
|
|
|
| |
It looks like the current way of marking objects was breaking
eightbitraptor's upcoming VWA changes and this seems to fix it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
The documentation says that the `end` pointer will be marked
but looking at the source, that is not the case.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
https://github.com/ruby/net-protocol/commit/40a1ab687c
|
| |
|
|
|
|
| |
https://github.com/ruby/net-protocol/commit/06d1420936
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/610
https://github.com/ruby/net-protocol/commit/7efa16d55d
|