RubyVM usage

[eregon]

Hello, it seems that currently rbs uses RubyVM::AbstractSyntaxTree in a couple places:
https://github.com/ruby/rbs/search?q=RubyVM&unscoped_q=RubyVM

However, RubyVM by design is MRI-only and is expected to not exist as a constant on alternative Ruby implementations (documentation).

Do you plan to address this somehow?
If AbstractSyntaxTree is needed by rbs then I think it's time to move it somewhere outside of RubyVM.

For instance, when running on TruffleRuby:

% rbs prototype rb lib/person.rb lib/email.rb lib/phone.rb
/Users/bfish/Documents/truffleruby-ws/truffleruby/mxbuild/truffleruby-native/jre/languages/ruby/lib/gems/gems/rbs-0.7.0/lib/rbs/prototype/rb.rb:55:in `const_missing': uninitialized constant RBS::Prototype::RB::RubyVM (NameError)
	from /Users/bfish/Documents/truffleruby-ws/truffleruby/mxbuild/truffleruby-native/jre/languages/ruby/lib/gems/gems/rbs-0.7.0/lib/rbs/prototype/rb.rb:55:in `parse'
	from /Users/bfish/Documents/truffleruby-ws/truffleruby/mxbuild/truffleruby-native/jre/languages/ruby/lib/gems/gems/rbs-0.7.0/lib/rbs/cli.rb:629:in `block in run_prototype_file'
	from /Users/bfish/Documents/truffleruby-ws/truffleruby/mxbuild/truffleruby-native/jre/languages/ruby/lib/gems/gems/rbs-0.7.0/lib/rbs/cli.rb:628:in `each'
	from /Users/bfish/Documents/truffleruby-ws/truffleruby/mxbuild/truffleruby-native/jre/languages/ruby/lib/gems/gems/rbs-0.7.0/lib/rbs/cli.rb:628:in `run_prototype_file'
	from /Users/bfish/Documents/truffleruby-ws/truffleruby/mxbuild/truffleruby-native/jre/languages/ruby/lib/gems/gems/rbs-0.7.0/lib/rbs/cli.rb:526:in `run_prototype'
	from /Users/bfish/Documents/truffleruby-ws/truffleruby/mxbuild/truffleruby-native/jre/languages/ruby/lib/gems/gems/rbs-0.7.0/lib/rbs/cli.rb:92:in `run'
	from /Users/bfish/Documents/truffleruby-ws/truffleruby/mxbuild/truffleruby-native/jre/languages/ruby/lib/gems/gems/rbs-0.7.0/exe/rbs:7:in `<top (required)>'
	from <internal:core> core/kernel.rb:395:in `load'
	from <internal:core> core/kernel.rb:395:in `load'
	from /Users/bfish/.rbenv/versions/tr-native/bin/rbs:23:in `<main>'

cc @bjfish

Relates to truffleruby/truffleruby#1671

[soutaro]

Good point!

I decided to use RubyVM::AbstractSyntaxTree because it's included MRuby and doesn't require additional dependencies. One option would be to make prototype commands an external library and uses parser gem (or something else if exists.)

[eregon]

because it's included MRuby

You mean CRuby, right? I think MRuby doesn't have RubyVM.

One option would be to make prototype commands an external library and uses parser gem (or something else if exists.)

Right, I think that would make sense.

I think moving and stabilizing AbstractSyntaxTree would also be valuable, it seems a few gems decided to use RubyVM::AbstractSyntaxTree but do not realize this is making the gem not portable across Ruby implementations, and using something experimental and unstable. (Just moving under ExperimentalFeatures would also be an option if not making it stable at the same time)

[soutaro]

Oh sorry, I mixed CRuby and MRI...

It's great to me too if AbstractSyntaxTree is stable and portable.

I think showing a better error message and exit gracefully is the first step we can do now.

[soutaro]

I don't think printing error messages is the best solution for this. Contributions for improvement are welcome.

[eregon]

Could we leave the issue opened?
The error message is an improvement but the original issue is still there: rbs prototype only works on CRuby.

[eregon]

I posted a comment related to this on the RubyVM::AbstractSyntaxTree on the CRuby tracker: https://bugs.ruby-lang.org/issues/14844#note-25

[soutaro]

Okay. Reopening this issue. (I don't think I have bandwidth to do this for a while, but someone else would have!)

[eregon]

FYI, a report about this on the truffleruby tracker: truffleruby/truffleruby#2691

[Earlopain]

rbs now has prism as a runtime dependency. Once rbs dops support for running on Ruby 3.2, I want to explore replacing RubyVM with prism where possible. Starting now would mean keeping RubyVM and prism support simulatiously because prism can't parse ruby 3.2 so it's a tad bit early still.

[eregon]

@soutaro Is there a plan to drop Ruby 3.2, if so when do you think it could happen?

If not soon, I wonder if we could just use the Prism 3.3 parser when running on Ruby 3.2.
Looking at https://github.com/ruby/ruby/blob/master/doc/NEWS/NEWS-3.3.0.md it seems there weren't any change to syntax from 3.2 to 3.3 (though that's probably not exhaustive).
Maybe it'd even make sense to support 3.2 in Prism if there are so few differences with 3.3 (cc @kddnewton).

That would also allow to remove the Ripper fallback for #2828.

[Earlopain]

There is:

• ruby/ruby@9930363 (https://bugs.ruby-lang.org/issues/18878)
• ruby/ruby@45cd011 (https://bugs.ruby-lang.org/issues/19281)
• ruby/ruby@bd04676 (https://bugs.ruby-lang.org/issues/19549)
• ruby/ruby@8980207 (https://bugs.ruby-lang.org/issues/19882)
• ruby/ruby@fe74674
• ruby/ruby@a607d62 (https://bugs.ruby-lang.org/issues/20033)
• ruby/ruby@ae76c8a (https://bugs.ruby-lang.org/issues/18980)
• ruby/ruby@a9f0961 (https://bugs.ruby-lang.org/issues/19370)
• ruby/ruby@67dd52d (https://bugs.ruby-lang.org/issues/19539)

(I look at the changelog for the parser gem, that is pretty exhaustive. Some changes may be subsequent fixes for changes during 3.3 development).

I don't want to implement these changes.

Mostly these look like fixes for code that nobody actually writes so parsing as 3.3 on 3.2 would probably be fine. But also, rbs seems pretty close to dropping rubies when they go EOL.