* Document Range#to_set
* Update Thread#raise and Fiber#raise signatures and docs
* Add reference to String#strip to character_selectors.rdoc
* Update *nil docs when calling methods
* Enhance Array#find and #rfind docs
* Add a notice to Kernel#raise about cause:
https://bugs.ruby-lang.org/issues/21785#note-10
> It is too late to introduce it in Ruby 4.0, let's aim for 4.1.
This reverts commits:
* d0b72429a93e54f1f956b4aedfc25c57dc7001aa
Add support for signed and unsigned LEB128 to pack/unpack.
* 68a900e30b4ca1537d7975c3a619fd94fca7b084
add news for pack / unpack directives
This commit adds a new pack format command `R` and `r` for unsigned and
signed LEB128 encoding. The "r" mnemonic is because this is a
"vaRiable" length encoding scheme.
LEB128 is used in various formats including DWARF, WebAssembly, MQTT,
and Protobuf.
[Feature #21785]
## Components
This PR adds functionality to visualize HIR using the [Iongraph](https://spidermonkey.dev/blog/2025/10/28/iongraph-web.html) tool first created for use with Spidermonkey.
## Justification
Iongraph's viewer is (as mentioned in the article above) a few notches above graphviz for viewing large CFGs. It also allows easily inspecting different compiler optimization passes and multiple functions in the same browser window. Since Spidermonkey is using this format, it may be beneficial to use it for our own JIT development.
The requirement for JSON is downstream from that of the Iongraph format. As for writing the implementation myself, ZJIT leans towards having fewer dependencies, so this is the preferred approach.
## How does it look?
<img width="902" height="957" alt="image" src="https://github.com/user-attachments/assets/e4e0991b-572a-41fd-9fed-1215bd1926c3" />
<img width="770" height="624" alt="image" src="https://github.com/user-attachments/assets/01398373-1f75-46b8-b1aa-7f5d4cbca6b8" />
Right now, it's aesthetically minimal, but is fairly robust.
## Functionality
Using `--zjit-dump-hir-iongraph` will dump all compiled functions into a directory named `/tmp/zjit-iongraph-{PROCESS_PID}`. Each file will be named `func_{ZJIT_FUNC_NAME}.json`. In order to use them in the Iongraph viewer, you'll need to use `jq` to collate them to a single file. An example invocation of `jq` is shown below for reference. The name of the file created does not matter to my understanding.
`jq --slurp --null-input '.functions=inputs | .version=2' /tmp/zjit-iongraph-{PROCESS_PID}/func*.json > ~/Downloads/foo.json`
From there, you can use https://mozilla-spidermonkey.github.io/iongraph/ to view your trace.
### Caveats
- The upstream Iongraph viewer doesn't allow you to click arguments to an instruction to find the instruction that they originate from when using the format that this PR generates. (I have made a small fork at https://github.com/aidenfoxivey/iongraph that fixes that functionality via 9e9c29b41c.patch)
- The upstream Iongraph viewer can sometimes show "exiting edges" in the CFG as being not attached to the box representing its basic block.
<img width="1814" height="762" alt="image" src="https://github.com/user-attachments/assets/afbbaa16-332f-498f-849e-11c69a8cb0cc" />
(Image courtesy of @tekknolagi)
This is because the original tool was (to our understanding) written for an SSA format that does not use extended basic blocks. (Extended basic blocks let you put a jump instruction, conditional or otherwise, anywhere in the basic block.) This means that our format may generate more outgoing edges than the viewer is written to handle.
