Matz was very positive to bundle it with Ruby 3.0, but just for case, I'd like to get approval from matz in a public ticket. I hope we can bundle it in 3.0 preview 2.
For TypeProf, please see my talk at RubyKaigi Takeout 2020:
Since TypeProf depends on CRuby bytecodes, probably it should be excluded on alternative implementations since it won't work?
Or maybe still ship it but raise a nice error if used on RUBY_ENGINE != "ruby"?
I think there might be expectations that all bundled gems for a given version are available on all Ruby implementations.
maybe still ship it but raise a nice error if used on RUBY_ENGINE != "ruby"?
Okay, I'll add it.
I think there might be expectations that all bundled gems for a given version are available on all Ruby implementations.
Sorry. In (far) future, I'd like to improve TypeProf to use AST instead of bytecodes if this project is considered successful. But it requires huge development resource, and there are still many TODOs for typeprof develpoment, so I cannot afford it in near future. (Some people including matz involved in the design of typeprof, but I have developed it alone.)
Sorry. In (far) future, I'd like to improve TypeProf to use AST instead of bytecodes if this project is considered successful. But it requires huge development resource, and there are still many TODOs for typeprof develpoment, so I cannot afford it in near future. (Some people including matz involved in the design of typeprof, but I have developed it alone.)
I think it's not a big issue if TypeProf is meant only as a CLI/standalone tool, and not a gem to require at runtime.
Then people can generate .rbs files on CRuby, but still do everything else on any other Ruby implementation.
(the AST has more information than bytecode, so I guess it could be useful for TypeProf, but it might be more work to process it)
Updated by 
Updated by 
Updated by 
Updated by