Repository navigation
RubyVM usage #348
Description
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
Activity
soutaro commentedon Jul 31, 2020
Good point!
I decided to use
RubyVM::AbstractSyntaxTreebecause it's included MRuby and doesn't require additional dependencies. One option would be to makeprototypecommands an external library and usesparsergem (or something else if exists.)eregon commentedon Jul 31, 2020
You mean CRuby, right? I think MRuby doesn't have
RubyVM.Right, I think that would make sense.
I think moving and stabilizing
AbstractSyntaxTreewould also be valuable, it seems a few gems decided to useRubyVM::AbstractSyntaxTreebut do not realize this is making the gem not portable across Ruby implementations, and using something experimental and unstable. (Just moving underExperimentalFeatureswould also be an option if not making it stable at the same time)soutaro commentedon Jul 31, 2020
Oh sorry, I mixed CRuby and MRI...
It's great to me too if
AbstractSyntaxTreeis stable and portable.I think showing a better error message and exit gracefully is the first step we can do now.
soutaro commentedon Aug 1, 2020
I don't think printing error messages is the best solution for this. Contributions for improvement are welcome.
eregon commentedon Aug 1, 2020
Could we leave the issue opened?
The error message is an improvement but the original issue is still there:
rbs prototypeonly works on CRuby.eregon commentedon Aug 1, 2020
I posted a comment related to this on the
RubyVM::AbstractSyntaxTreeon the CRuby tracker: https://bugs.ruby-lang.org/issues/14844#note-25soutaro commentedon Aug 1, 2020
Okay. Reopening this issue. (I don't think I have bandwidth to do this for a while, but someone else would have!)
eregon commentedon Jul 16, 2022
FYI, a report about this on the truffleruby tracker: truffleruby/truffleruby#2691
Earlopain commentedon Jan 27, 2026
rbsnow hasprismas a runtime dependency. Oncerbsdops support for running on Ruby 3.2, I want to explore replacingRubyVMwithprismwhere possible. Starting now would mean keepingRubyVMandprismsupport simulatiously becauseprismcan't parse ruby 3.2 so it's a tad bit early still.eregon commentedon Jan 27, 2026
@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 commentedon Jan 27, 2026
There is:
(I look at the changelog for the
parsergem, 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.
kddnewton commentedon Jan 27, 2026
Honestly if we're just parsing comments, it would probably be fine to use prism for 3.2, I can't imagine there are enough differences for it to matter.
Also just as an aside, we should be using
Prism.parse_commentsbecause then it won't reify the whole AST.Earlopain commentedon Jan 27, 2026
It uses rubyvm for code and ripper for comments (because that's not returned by rubyvm). I guess rubyvm was just more convenient to use.
I use
parse_commentsin the PR to replace ripper but once prism can be used for code as well then there's no point in doing it twice.kddnewton commentedon Jan 27, 2026
Ahh I misunderstood, yes we should be using prism for both.
Another option for migration is to write a translation layer to RubyVM::AST. Honestly I've considered it for a while, and it is probably a good idea in case there are other stragglers as well.
eregon commentedon Jan 27, 2026
Probably the wrong place to discuss this but anyway: 😅
The problem there is just defining
::RubyVMon JRuby/TruffleRuby breaks a bunch of gems which assume thatif defined?(RubyVM)then e.g.RubyVM::InstructionSequenceexists and is functional (which wouldn't be the case).So it wouldn't be feasible for JRuby/TruffleRuby to implement
RubyVM::Anything, basically ever.My short conclusion is RubyVM should not exist (it's a collection of things that were not properly discussed or designed and just stashed there in a WIP state), and so we should really try to minimize usages and eventually deprecate & replace it by proper APIs.
For RubyVM::AST there is already a great replacement, Prism, so I think it's time to migrate away from RubyVM::AST, deprecate it and finally remove it.
IOW I'd much rather implement the 3.2 syntax in Prism than adding a translation layer for RubyVM::AbstractSyntaxTree. But maybe we need neither if rbs can drop 3.2 support soon.
eregon commentedon Aug 24, 2026
Now that
rbsdropped Ruby 3.2 support (#2830) it's possible to migrate to Prism without having 2 implementations.@Earlopain Are you still interested to pick that up? :)
Earlopain commentedon Aug 25, 2026
I'll take a look, yeah.
Earlopain commentedon Aug 31, 2026
I openend #3105 and #3140. I left out the runtime prototyping since that is deprecated anyways.
I split it out into two PR to make it easier to review but by nature of the change its pretty big regardless. I would appreciate a review if someone can spare the time.