[prototype runtime] Add --autoload option

[ksss]

I've added the --autoload option to include objects from autoload destinations as analysis targets.

rbs prototype runtime has an issue where it cannot read from autoload destinations, unlike rbs prototype rb. To resolve this, I've added an option to forcibly load Module#autoload.

Using TracePoint, it target Module#autoload to hook and retrieve its arguments, which are then loaded later. There is an issue where nested autoload cannot be read, but in most cases, it resolves the problem.

Since it's using the target option of TracePoint#enable, there's hardly any performance degradation.

Example

before

$ bundle exec rbs prototype runtime -r rack 'Rack::*' 2>/dev/null | wc
       4       6      36

after

$ bundle exec rbs prototype runtime -r rack --autoload 'Rack::*' 2>/dev/null | wc
    2076    5331   44641

[soutaro]

@ksss

Thank you for working for this issue. I have two questions:

1. Should we load the autoloaded constants by default?
2. It seems like enumerating all (possibly autoloaded) constants by Module#constants and Kernel.autoload? is a better implementation, but it requires a lot more rewrite in prototype/runtime.rb. What do you think?

[ksss]

1. Should we load the autoloaded constants by default?

Setting this option as default seems challenging, but it appears to be a good idea.
One risk is having to deal with unexpected errors, but most problems can be anticipated.

It seems like enumerating all (possibly autoloaded) constants by Module#constants and Kernel.autoload? is a better implementation, but it requires a lot more rewrite in prototype/runtime.rb. What do you think?

Indeed, it's possible to load autoload using the Module#constants method and then Object.const_get.
Furthermore, by running it recursively, it can handle nested autoloads.
It's a bit complicated, but I have implemented the same process before.

However, if there's no autoload at all, the concern is that unnecessary processing might degrade performance.
At the library level, it might be within the margin of error, but as the scale becomes as large as a Rails application, performance issues are more likely to arise.
We might need to narrow down the root for executing Module#constants based on the specified pattern.

Using the TracePoint method, if we specify the target with the enable method, there's hardly any performance degradation.

There are trade-offs.

---

Anyway, adding more features to the runtime will likely require significant rewriting.
For example, if we're using RBS::Prototype::Runtime as a library rather than from the CLI, as in this PR, the autoload loading feature won't be enabled. It's necessary to include the loading phase within the class.

[ksss]

There's also a multi-step approach.

Step 1: Offer the --autoload option with a default of (true or false). Keep code changes to a minimum. Using TracePoint.
Step 2: Offer the --autoload option with a default of true. Undertake a major rewrite. Using Module#constants. Maybe for RBS v4?

[soutaro]

Got it! Let's merge this PR for the next version of RBS. Using tracepoint, defaults to false.