RubyVM usage

@bjfish

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

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.)

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)

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.

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

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.

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

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

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

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.

@soutaro

@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.

There is:

(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.

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_comments because then it won't reify the whole AST.

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_comments in the PR to replace ripper but once prism can be used for code as well then there's no point in doing it twice.

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.

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.

Probably the wrong place to discuss this but anyway: 😅
The problem there is just defining ::RubyVM on JRuby/TruffleRuby breaks a bunch of gems which assume that if defined?(RubyVM) then e.g. RubyVM::InstructionSequence exists 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.

@Earlopain

Now that rbs dropped 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? :)

I'll take a look, yeah.

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.

Navigation Menu

Repository navigation

RubyVM usage #348

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

RubyVM usage #348

Description

Activity

soutaro commented on Jul 31, 2020

eregon commented on Jul 31, 2020

soutaro commented on Jul 31, 2020

soutaro commented on Aug 1, 2020

eregon commented on Aug 1, 2020

eregon commented on Aug 1, 2020

soutaro commented on Aug 1, 2020

eregon commented on Jul 16, 2022

Earlopain commented on Jan 27, 2026

eregon commented on Jan 27, 2026

Earlopain commented on Jan 27, 2026

kddnewton commented on Jan 27, 2026

Earlopain commented on Jan 27, 2026

kddnewton commented on Jan 27, 2026

eregon commented on Jan 27, 2026

eregon commented on Aug 24, 2026

Earlopain commented on Aug 25, 2026

Earlopain commented on Aug 31, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions