ruby-next / ruby-next Goto Github PK

See https://bugs.ruby-lang.org/issues/16828

Hello,

I just ran into a troubling issue and tracked it back to here. I guess it could also be RVM issue.

What did you do?

When I did bundle install and bundle exec puma my app could not start on a brand new VM.
I got an error:

RuntimeError: Gem's lib is not in the $LOAD_PATH: /home/vagrant/.rvm/rubies/jruby-9.2.9.0/lib/ruby/gems/shared/gems/anyway_config-2.0.6/lib 

Additional context

Here is the error:

Puma starting in single mode...
* Version 5.0.4 (jruby 9.2.9.0 - ruby 2.5.7), codename: Spoony Bard
* Min threads: 0, max threads: 16
* Environment: development
! Unable to load application: RuntimeError: Gem's lib is not in the $LOAD_PATH: /home/vagrant/.rvm/rubies/jruby-9.2.9.0/lib/ruby/gems/shared/gems/anyway_config-2.0.6/lib

Solution

I traced back the problem using prints: 

"Looking at /home/vagrant/.rvm/rubies/jruby-9.2.9.0/lib/ruby/gems/shared/gems/anyway_config-2.0.6/lib in [\"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/bundler-2.2.18/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/websocket-1.2.8/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/slim-4.1.0/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/sinatra-contrib-2.1.0/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/sinatra-2.1.0/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/ruby-next-0.10.5/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/unparser-0.5.7/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/ruby-next-parser-3.0.1.0/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/redis-4.2.3/lib\",
 \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/rack-protection-2.1.0/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/rack-cors-1.1.1/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/rack-2.2.3/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/puma-5.0.4-java/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/parser-3.0.1.1/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/nio4r-2.5.4-java/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/mustermann-1.1.1/lib\",
 \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/ruby2_keywords-0.0.2/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/multi_json-1.15.0/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/mprelude-0.1.0/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/procto-0.0.3/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/litecable-0.7.0/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/haml-5.2.1/lib\", 
\"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/tilt-2.0.10/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/temple-0.8.2/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/diff-lcs-1.4.4/lib\", 
\"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/concord-0.1.6/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/ast-2.4.2/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/anyway_config-2.0.6/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0@global/gems/ruby-next-core-0.10.5/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/anima-0.3.2/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/equalizer-0.0.11/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/adamantium-0.2.0/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/memoizable-0.4.2/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/thread_safe-0.3.6-java/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/ice_nine-0.11.2/lib\", \"/home/vagrant/.rvm/gems/jruby-9.2.9.0/gems/abstract_type-0.0.7/lib\", \"/home/vagrant/.rvm/rubies/jruby-9.2.9.0/lib/ruby/2.5/site_ruby\", \"/home/vagrant/.rvm/rubies/jruby-9.2.9.0/lib/ruby/stdlib\"]"

I found out that I had two current gemsets and gems were not all available the $LOAD_PATH.

Thanks to StackOverflow MPapis’ answer:
https://stackoverflow.com/questions/12307217/rvm-list-all-gems-in-current-gemset-ignoring-global-default/16968309

I just found out that I had two environment variables: GEM_PATH and GEM_HOME and by tweaking them I solved my issue.

$ echo $GEM_HOME
> /home/vagrant/.rvm/gems/jruby-9.2.9.0
$ echo $GEM_PATH
> /home/vagrant/.rvm/gems/jruby-9.2.9.0:/home/vagrant/.rvm/gems/jruby-9.2.9.0@global
$ GEM_PATH=$GEM_HOME bundle install 

This installed the Gems using only one GEM_PATH entry, so now all the gems are available to Ruby-Next.

I did not try to solve the issue by patching, but I suppose it is not that complicated. Here is a solution for people encountering the same issue ! 

Environment

Ruby version: JRuby 9.2.9.0 (2.5.7), OpenJDK

Ruby Next version: 0.10.5

Parser version: 3.0.1.1

Unparser version: 0.5.7

From #100 (comment)

It'd be really useful for experiments and in some usages to be able to just replace the files and e.g. desugar the pattern matching in them.

For instance if the files are tracked in git anyway, the easiest way to run locally some Ruby files using pattern matching would be to use this inplace rewrite, and then just throw away the changes when running on a Ruby which supports pattern matching.

Another example is if tests use pattern matching, it'd be convenient to just rewrite those tests inplace, and run them on a Ruby not supporting pattern matching.

It would also be convenient to benchmark desugared vs original for pattern matching.

Is there a way to know the file system path of the file that is being rewritten in a custom rewriter, particularly in the #safe_rewrite method?

What did you do?

Rake rake -T (or anything evokes bundler), when ruby-next's entry in $LOAD_PATH includes a symlink.

What did you expect to happen?

I expect the command to complete successfully without errors.

What actually happened?

TypeError: no implicit conversion from nil to integer @ lib/ruby-next/setup_self.rb#L17

Additional context

There are a couple places where ruby-next hunts for itself (or another gem) inside of $LOAD_PATH; however, the path it searches for is actually its realpath. If its entry in $LOAD_PATH includes a symlink, it will fail to find itself, resulting in an error.

Example

Say $LOAD_PATH == ["/srv/my-server/ruby/gems/2.6.0/gems/ruby-next-core-0.12.0/lib"], but /srv/my-server/ruby is a symlink to /var/lib/ruby.

Then the line lib_path = File.realpath(File.join(__dir__, "..")) (from setup_self.rb) will return /var/lib/ruby/gems/2.6.0/gems/ruby-next-core-0.12.0/lib. Then the next line ($LOAD_PATH.index(lib_path)) will return nil.

Potential solutions

I'm too inexperienced with this code to know what an ideal solution would be, but I would try:

• Don't realise symlinks. Instead of File.realpath(File.join(__dir__, "..")), just do File.join(__dir__, "..").
• When searching $LOAD_PATH, realise all its entries first. I have an example of this below.

Lame proof-of-concept patch

The very-naive patch below "fixes" this bug, but it's pretty lame. I would submit a pull-request, but I'm not familiar enough with this code not to make a mess of it. Hopefully this is enough to give you some ideas on a proper fix.

diff --git a/lib/ruby-next/language/setup.rb b/lib/ruby-next/language/setup.rb
index dc0f266..eee9667 100644
--- a/lib/ruby-next/language/setup.rb
+++ b/lib/ruby-next/language/setup.rb
@@ -49,7 +49,7 @@ module RubyNext
 
         GemTranspiler.maybe_transpile(File.dirname(dirname), lib_dir, next_dirname) if transpile
 
-        current_index = $LOAD_PATH.find_index do |load_path|
+        current_index = $LOAD_PATH.map { |p| File.realpath(p) rescue p }.find_index do |load_path|
           Pathname.new(load_path).cleanpath.to_s == dirname
         end
 
diff --git a/lib/ruby-next/setup_self.rb b/lib/ruby-next/setup_self.rb
index c745cbf..ce2a07d 100644
--- a/lib/ruby-next/setup_self.rb
+++ b/lib/ruby-next/setup_self.rb
@@ -6,7 +6,7 @@
 version = RubyNext.next_ruby_version
 next_dirname = File.join(__dir__, "..", ".rbnext")
 lib_path = File.realpath(File.join(__dir__, ".."))
-current_index = $LOAD_PATH.index(lib_path)
+current_index = $LOAD_PATH.map { |p| File.realpath(p) rescue p }.index(lib_path)
 
 loop do
   break unless version

Environment

Ruby version: 2.6.6

Ruby Next version: v0.12.0

Parser version: I'm not sure what this is.

Unparser version: My apologies, but I don't know what this refers to either.

https://bugs.ruby-lang.org/issues/19015

See https://bugs.ruby-lang.org/issues/15198

ruby/ruby#6216

FYI, I just pushed my Ractor backport, which could be useful for ruby-next 😸

Let me know if I can help.

https://bugs.ruby-lang.org/issues/18980

What did you do?

I was updating my dependencies on https://github.com/Mayurifag/rails-vue-fullstack-ultimate-template/tree/update-deps project. After making bump to ruby 3.0.2 and bundle update I've got an issue with anyway_config and its dependence ruby-next-core-0.13.0/

After trying to do anything rails related, I've got this:

Creating rails-vue-fullstack-ultimate-template_backend_run ... done
/bundle/ruby/3.0.0/gems/ruby-next-core-0.13.0/lib/ruby-next/language/setup.rb:53:in `realpath': No such file or directory @ rb_check_realpath_internal - /bundle/ruby/3.0.0/gems/rails-6.1.4.1/lib (Errno::ENOENT)
	from /bundle/ruby/3.0.0/gems/ruby-next-core-0.13.0/lib/ruby-next/language/setup.rb:53:in `realpath'
	from /bundle/ruby/3.0.0/gems/ruby-next-core-0.13.0/lib/ruby-next/language/setup.rb:53:in `block in setup_gem_load_path'
	from /bundle/ruby/3.0.0/gems/ruby-next-core-0.13.0/lib/ruby-next/language/setup.rb:52:in `find_index'
	from /bundle/ruby/3.0.0/gems/ruby-next-core-0.13.0/lib/ruby-next/language/setup.rb:52:in `setup_gem_load_path'
	from /bundle/ruby/3.0.0/gems/anyway_config-2.1.0/lib/anyway_config.rb:6:in `<main>'
	from /bundle/ruby/3.0.0/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `require'
       ...

Additional context

When I've added gem "ruby-next-core", "< 0.13.0" into gemfile, it probably fixed the issue.

Environment

Ruby version: 3.0.2 (not 2.x as in github template)

ruby/ruby@fa87f72
ruby/ruby@2186347

(Could be implemented similarly to find pattern).

What did you do?

Trying to rewrite a Symbol array using percent notation, from this

%i[loader @loading]

to

%i[loader @loading_rewritten]

What actually happened?

The source before rewriting seems to replace the array with a few weird characters...

%i_A5Я_ing]

and that is before anything is rewritten.

Additional context

Using this code to debug...

def safe_rewrite(source)
  pp source
  pp source.include?('%i[loader @loading]')
end

The include? call always returns false, even though the %i[loader @loading] exists in the source.

thx.

Introduced in Ruby 3.2. I came here looking for a polyfill so I can support it in my library 😅.

test.rb:

p Object.new&.object_id

$ ruby-next -V --min-version=2.2.0 nextify test.rb         
RubyNext core strategy: refine
RubyNext transpile mode: rewrite
Remove old files: ./.rbnext
Generated: ./.rbnext/2.3/test.rb

$ cat ./.rbnext/2.3/test.rb
p ((!Object.new.nil? || nil) && Object.new.object_id)

But the LHS, Object.new should only be evaluated once.

Environment

Ruby version: 2.7

Ruby Next version: 0.11.1

This patch changes the way a standalone in operator works: instead of returning false now we raise an exception if there is no match.

Ref https://bugs.ruby-lang.org/issues/17744

Hi guys, first of all, thank you for reading this request and I apologize in advance if my understanding of Ruby is not deep / misjudged.

We have a project that uses anyway_config gem and thus have ruby-next as a indirect dependency.

My context is that:

I have a project of AWS Lambdas written in Ruby. As we are using the Serverless framework, and specifically the ruby-package plugin to help us package our external deps (gems), it was required for us to install the gems with Bundler's standalone mode.

In our project's case, we do bundle install --standalone --path vendor/bundle
As such, the generated bundler/setup.rb looks something like this (notice the use of relative path resolution /../):

# ./vendor/bundle/bundler/setup.rb
require 'rbconfig'
ruby_engine = RUBY_ENGINE
ruby_version = RbConfig::CONFIG["ruby_version"]
path = File.expand_path('..', __FILE__)
# ... [redacted]
$:.unshift "#{path}/../#{ruby_engine}/#{ruby_version}/gems/ruby-next-core-0.10.5/lib"
$:.unshift "#{path}/../#{ruby_engine}/#{ruby_version}/gems/anyway_config-2.0.6/lib"

I can see from Bundler's code base that for standalone mode, the gems' lib path are always relative paths to the setup.rb file

As such, $LOAD_PATH can have gem files' lib path to have non-fully-resolved paths (e.g., /../).

I was wondering if ruby-next's language/setup.rb should try to resolve path first before comparison?
https://github.com/ruby-next/ruby-next/blob/master/lib/ruby-next/language/setup.rb#L51-L53

-     current_index = $LOAD_PATH.index(dirname)
+     current_index = $LOAD_PATH.map { |p| Pathname.new(p).cleanpath.to_s }.index(dirname)

      raise "Gem's lib is not in the $LOAD_PATH: #{dirname}" if current_index.nil?

Sorry for the long explanation, but this was coming from a discussion here:
palkan/anyway_config#71

Related to this palkan/anyway_config#103

The issue is here:
https://github.com/palkan/anyway_config/blob/master/lib/anyway/tracing.rb#L10

Truffleruby will claim 3.0.3 in RUBY_VERSION but doesn't yet support endless method definition.

It would be great to have runtime transpiling support for IRB/Pry.

For example:

$ irb
> x = 1
> y = 2
> d = {x:, y:}
{x: 1, y: 2}

Thoughts on implementation

It looks that the only way to do that is to monkey-patch eval somewhere inside the console code.

For example, IRB uses Workspace#evaluate: https://github.com/ruby/irb/blob/5af637b3c17f85c15a32416bc5b4579307873833/lib/irb/workspace.rb#L118

In order to activate the monkey-patch, we can use configuration files: .irbrc and .pryrc.

The open question is how to include refinements (using RubyNext); can we call binding.eval("using RubyNext") 🤔

I'm trying to run some small scripts on Ruby 2.0.0 (to compare performance), and one issue I'm seeing is that something like 1 + 2i doesn't parse on 2.0.
The 2i notation was added in Ruby 2.1.

Do you think this is something that would make sense to support in ruby-next?

Note that I don't request support for Ruby 2.0, just transpiling 2i to 2.i.
I actually got some script using case in working on 2.0 with:

ruby-next core_ext -o ruby-next.rb
ruby-next -V --min-version=2.0 nextify script.rb
ruby -r./backport.rb -r./ruby-next.rb .rbnext/2.7/script.rb

https://bugs.ruby-lang.org/issues/16122

See 1d8cd8f#commitcomment-40558880

What did you do?

I have a custom rewriter...

require 'ruby-next/language'

module Proscenium
  module CssModule
    class Rewriter < RubyNext::Language::Rewriters::Text
      NAME = 'proscenium-css-module'

      def safe_rewrite(source)
        source.gsub(/:@([\w_]+)/) do |_|
          context.track! self

          match = ::Regexp.last_match(1)
          pp "Proscenium::CssModule::Name.new(:@#{match}, css_module(:#{match}))"
        end
      end
    end
  end
end

RubyNext::Language.rewriters << Proscenium::CssModule::Rewriter
require 'ruby-next/language/runtime'

What did you expect to happen?

This should replace :@something with Proscenium::CssModule::Name.new(:@something, css_module(:something)), and it does work on one of my Rails apps, but not in another. There are obviously differences between the two apps, but they are many and numerous, so it's impossible to run a like for like comparison.

It's almost like something else is reverting the rewrite somewhere.

What actually happened?

With a bit of puts logging, I can see that the rewriter is being called and is returning the "Proscenium::CssModule::Name.new(:@#{match}, css_module(:#{match}))" string. But when the page is rendered, the rewrite is somehow reverted.

So this...

:@breadcrumbs

Gets logged as...

Proscenium::CssModule::Name.new(:@breadcrumbs, css_module(:breadcrumbs))

but is rendered as

:@breadcrumbs

as if it was unchanged.

Environment

Ruby version: 3.2.2

thx

I’m lead maintainer of https://github.com/fastlane/fastlane and I’m so excited about this. I’ve been wanting to use features from newer Ruby versions for so long but not able to since we have been supporting Ruby 2.1 and up for so long.

We have just recently bumped up our minimum to Ruby 2.4 and will probably keep at this for as long as we can. I totally want to respect your time but I am curious in what the effort level would be to support add support down to Ruby 2.4.

I really appreciate all the work you’ve done with this. I’m looking forward to adding this to fastlane as soon as we are able to 😊

From #100 (comment)

It'd be nice to have something like require "ruby-next/language/runtime" which also handles eval.

Using using RubyNext::Language::Eval from #100 (comment) is inconvenient because I'd need to add it to every test file using eval.

From #100 (comment)

So we'd run ruby-next nextify to create the files, and paste something like $LOAD_PATH.unshift "#{__dir__}/.rbnext" but wouldn't need any require 'ruby-next'.
The reason is the transpiled files would only be used on some Ruby implementations, and we wouldn't to add a dependency to the gem for all Ruby implementations.

This mostly already works with ruby-next nextify -V --rewrite=pattern-matching --no-refine ./lib, but would need documentation in https://github.com/ruby-next/ruby-next#integrating-into-a-gem-development

Hi @palkan,

I've noticed an inconsistency in the recent ruby-next release regarding the polyfill for Data classes.

While standard Ruby Data classes support initialization using both *args and **kwargs, the polyfill appears to only support **kwargs

I receive smth like this in my mock gem ruby-2.* CI builds

I'm eager to contribute a fix for this issue. However, I'm uncertain about the testing strategy for this behavior. I see some related specs

Thank you!

Related to #41.

ruby-next nextify --rewrite=...

Currently, we can only specify the target Ruby version for transpiling. It works great for MRI-compatible Rubies but could be not so useful for others (e.g., mruby).

To make UX better, we can provide an alternative way of specifying the target: passing rewriters explicitly. For example:

ruby-next nextify ./lib --rewrite=pattern-matching --rewrite=endless-method

NOTE: --single-version is enforced in that case.

ruby-next --list-rewriters

In addition to that, we also need a helper command: ruby-next nextify --list-rewriters. It could be used to show the list of available rewriters:

$ ruby-next nextify --list-rewriters

endless-range ("[0, 1][1..]")
endless-method ("obj = Object.new; def obj.foo() = 42")
numbered-params ("proc { _1 }.call(1)")
pattern-matching ("case 0; in 0; true; else; 1; end")
...

We can use class names as identifiers (class_name == id.split("-").map(&:capitalize).join) and SYNTAX_PROBE as examples in the output.

NOTE: --min-version couldn't be used simultaneously with --rewrite.

Links:

• https://bugs.ruby-lang.org/issues/14781
• https://blog.saeloun.com/2019/11/27/ruby-2-7-enumerator-produce

What did you do?

Attempted to Use Ruby-Next With Standardrb

With standardrb, I get an ArgumentError exception that says "Malformed version number string" when using "next" as the ruby_version as described in the documentation.

# .standard.yml
require:
  - ruby-next/rubocop
ruby_version: 'next'
parallel: true
ignore:
  - 'lib/.rbnext/**/*'

$ standardrb
Users/$USER/.rvm/rubies/ruby-2.7.3/lib/ruby/2.7.0/rubygems/version.rb:215:in `initialize': Malformed version number string next (ArgumentError)
from /Users/$USER/.rvm/rubies/ruby-2.7.3/lib/ruby/2.7.0/rubygems/version.rb:206:in `new'
from /Users/$USER/.rvm/rubies/ruby-2.7.3/lib/ruby/2.7.0/rubygems/version.rb:206:in `new'
from /Users/$USER/.rvm/gems/ruby-2.7.3@tmo_ops_utils/gems/standard-1.3.0/lib/standard/loads_yaml_config.rb:27:in `construct_config'
from /Users/$USER/.rvm/gems/ruby-2.7.3@tmo_ops_utils/gems/standard-1.3.0/lib/standard/loads_yaml_config.rb:12:in `call'
from /Users/$USER/.rvm/gems/ruby-2.7.3@tmo_ops_utils/gems/standard-1.3.0/lib/standard/builds_config.rb:19:in `call'
from /Users/$USER/.rvm/gems/ruby-2.7.3@tmo_ops_utils/gems/standard-1.3.0/lib/standard/cli.rb:13:in `run'
from /Users/$USER/.rvm/gems/ruby-2.7.3@tmo_ops_utils/gems/standard-1.3.0/exe/standardrb:7:in `<top (required)>'
from /Users/$USER/.rvm/gems/ruby-2.7.3@tmo_ops_utils/bin/standardrb:23:in `load'
from /Users/$USER/.rvm/gems/ruby-2.7.3@tmo_ops_utils/bin/standardrb:23:in `<main>'
from /Users/$USER/.rvm/gems/ruby-2.7.3@tmo_ops_utils/bin/ruby_executable_hooks:22:in `eval'
from /Users/$USER/.rvm/gems/ruby-2.7.3@tmo_ops_utils/bin/ruby_executable_hooks:22:in `<main>'

Attempted to Use Ruby-Next With RuboCop v1.20.0 and the Standardrb Configuration

# .rubocop.yml
require:
  - ruby-next/rubocop
  - standard

inherit_gem:
  standard: config/base.yml

AllCops:
  TargetRubyVersion: 'next'
  Exclude:
    - "lib/.rbnext/**/*"

# note that there was much trimming of output, which is quite verbose under rubocop,
# but it completed without actual exceptions.

$ rubocop
foo.gemspec:16:32: C: Gemspec/RequiredRubyVersion: required_ruby_version (2.7, declared in foo.gemspec) and TargetRubyVersion (3.01, which may be specified in .rubocop.yml) should be equal.
# almost (or possibly all) Lint/Syntax warnings:
(Using Ruby 3.01 parser; configure using TargetRubyVersion parameter, under AllCops`)

Please note that commenting out the inherit_gem directive and the standardrb YAML didn't change the result in any way, except to make RuboCop complain about more things.

What did you expect to happen?

1. I expected standardrb to run with ruby_version: 'next' defined, similar to what's supposed to happen with RuboCop, without raising exceptions.
2. I expected RuboCop not to complain about TargetRubyVersion when set to next per the README.
3. I expected ruby-next to handle the use case where the gemspec specifies a minimum Ruby version without complaint, since Ruby-Next is in the runtime dependencies and should handle it smoothly.

What actually happened?

1. I got exceptions when running standardrb.
2. I got lots of version mismatch complaints from RuboCop when run directly.

Additional Comments

The addition or removal of additional RuboCop gems like rubocop-rake and rubocop-spec made no difference to the end result in any runs. The same errors were raised. However, it's not clear from the documentation how, where, or if additional RuboCop gems should be required within the YAML files.

Environment

• macOS 11.6
• GNU bash, version 5.1.8(1)-release (x86_64-apple-darwin20.3.0)
• RVM running Ruby 2.7.3p183
• bundler 2.1.4
• bundled gems include:
  • parser 3.0.2.0
  • rubocop 1.20.0
  • rubocop-rake 0.6.0
  • rubocop-rspec 2.5.0
  • ruby-next 0.13.1
  • ruby-next-core 0.13.1
  • standard 1.3.0
  • unparser 0.6.0

https://bugs.ruby-lang.org/issues/15822

ruby/ruby@4adb012

What did you do?

Produced a jar file using warbler.

What did you expect to happen?

The project/code to run as it does without the jar file

What actually happened?

Error within tracing.rb for invalid syntax

Additional context

https://github.com/zacheryph/ruby-next-jruby-jar-test

Environment

Ruby version: Jruby 9.2.11.1

Ruby Next version:
0.8.0 (using Anyway Config as how I originally stumbled upon this)

The features from Ruby 3.1 currently missing in Ruby Next.

Syntax

• * Command syntax in endless methods (def foo() = puts "bar"): https://bugs.ruby-lang.org/issues/17398

* We only need to support this for Ruby 3.0. Older Rubies are automatically supported (since Parser recognizes this syntax and we transpile it).

API

• Enumerable#compact: https://bugs.ruby-lang.org/issues/17312
• Integer.try_convert: https://bugs.ruby-lang.org/issues/15211, ruby/ruby@301d194
• MatchData#match: https://bugs.ruby-lang.org/issues/18172, ruby/ruby@09d724e
• **Kernel#load with a wrapping Module: https://bugs.ruby-lang.org/issues/6210, ruby/ruby@b35b7a1

** Not sure we want to support this one; but that could be an interesting challenge 🙂

https://bugs.ruby-lang.org/issues/16746

What did you do?

Included the anyway_config gem into a Rails project.

What did you expect to happen?

It should not segfault.

What actually happened?

Segfaults happen randomly in code unrelated to anyway_config.

Additional context

I've uploaded a reproduction script to the Ruby bug tracker.

The segfaults do not happen using anyway_config v2.0.0.pre2, and do happen using v2.0.0.rc1. The newer version introduced ruby-next, so I'm assuming that is the cause.

Only happens on Ruby 2.7.x. Ruby 3.0.3 and 3.1.1 both appear to be ok.

I'm not sure if you'll be able to fix this or if it's a Ruby core bug, but I thought I would report it here anyway.

Environment

Ruby version: 2.7.5

Ruby Next version: ruby-next-core (0.14.1)

Parser version: parser (3.1.1.0)

Unparser version: not used.

Please, open an issue if you would like us to support older Ruby versions.

First of all, thanks for the hard work everyone! I'm super excited for this project. Unfortunately I'm stuck with Ruby 2.2 (MRI) at work. Would love to see support for our very old version.

Any plans to support rubies as far back as 2.2?

What did you do?

From #100 (comment)

ruby-next nextify -V --rewrite=pattern-matching ./test/*_test.rb

What did you expect to happen?

It rewrites every file of that glob.

What actually happened?

It seems to only consider the first file.

What did you do?

8b.rb is from https://github.com/eregon/adventofcode/blob/a5fea350d30370c6317e2f365338030ef096cbf6/2020/8b.rb

$ ruby -v 8b.rb
ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]
8b.rb:7: warning: Pattern matching is experimental, and the behavior may change in future versions of Ruby!
8b.rb:32: warning: Pattern matching is experimental, and the behavior may change in future versions of Ruby!
761

$ ruby-next -V --single-version --no-refine nextify 8b.rb
RubyNext core strategy: core_ext
RubyNext transpile mode: rewrite
Failed to transpile 8b.rb: SyntaxError — unexpected token tLCURLY

The &. of line 41 seems the issue, removing the & lets it parse.

Environment

Ruby version: 2.7.2
Ruby Next version: 0.11.1

https://bugs.ruby-lang.org/issues/16378

Unfortunately, I'm sure about this issue. Does it belong to ruby-next or to parser? That's why it's a feedback.

Ruby 3.1.2

we have this 2 lines

some_spec.rb

mock_board_api_request board, query: # line 5
mock_lists_api_request lists, query: # line 6

Definitely, it's syntax error. We have this error message with ruby-next. It doesn't have info about file and line with syntax error.

SyntaxError:
  unexpected token tIDENTIFIER
# /home/pavel/.rvm/gems/ruby-3.1.2/gems/ruby-next-core-0.15.3/lib/ruby-next/language/parser.rb:43:in `rescue in parse'
# /home/pavel/.rvm/gems/ruby-3.1.2/gems/ruby-next-core-0.15.3/lib/ruby-next/language/parser.rb:36:in `parse'
# /home/pavel/.rvm/gems/ruby-3.1.2/gems/ruby-next-core-0.15.3/lib/ruby-next/language.rb:160:in `block in rewrite'
# /home/pavel/.rvm/gems/ruby-3.1.2/gems/ruby-next-core-0.15.3/lib/ruby-next/language.rb:156:in `each'
# /home/pavel/.rvm/gems/ruby-3.1.2/gems/ruby-next-core-0.15.3/lib/ruby-next/language.rb:156:in `inject'
# /home/pavel/.rvm/gems/ruby-3.1.2/gems/ruby-next-core-0.15.3/lib/ruby-next/language.rb:156:in `rewrite'
# /home/pavel/.rvm/gems/ruby-3.1.2/gems/ruby-next-core-0.15.3/lib/ruby-next/language.rb:103:in `transform'
# /home/pavel/.rvm/gems/ruby-3.1.2/gems/ruby-next-core-0.15.3/lib/ruby-next/language/runtime.rb:34:in `transform'
# /home/pavel/.rvm/gems/ruby-3.1.2/gems/ruby-next-core-0.15.3/lib/ruby-next/language/runtime.rb:25:in `load'
# /home/pavel/.rvm/gems/ruby-3.1.2/gems/ruby-next-core-0.15.3/lib/ruby-next/language/runtime.rb:112:in `load'
# ------------------
# --- Caused by: ---
# Parser::SyntaxError:
#   unexpected token tIDENTIFIER
#   /home/pavel/.rvm/gems/ruby-3.1.2/gems/parser-3.1.3.0/lib/parser/diagnostic/engine.rb:72:in `process'

Without ruby-next we have this message. Looks like it's better message

some_spec.rb:6: syntax error, unexpected string literal, expecting `do' or '{' or '('

Is it abour ruby-next or about parser?

What did you do?

1. Installed JRuby-9.2.19.0
2. Installed Ruby-Next v0.13.1
3. Ran the same endless def you have in the quickstart section of your README.

What did you expect to happen?

For the code to print 👽 without errors.

What actually happened?

The code appeared to execute properly, in the sense that the endless def printed the correct value, but JRuby still raised:

SyntaxError: -e:2: syntax error, unexpected '='
def greet(val) =
               ^
👽

Environment

jruby --version

jruby 9.2.19.0 (2.5.8) 2021-06-15 55810c552b OpenJDK 64-Bit Server VM 17+0 on 17+0 +jit [darwin-x86_64]

jruby -e 'puts RUBY_VERSION'

2.5.8

gem list ruby-next

*** LOCAL GEMS ***

ruby-next (0.13.1)
ruby-next-core (0.13.1)
ruby-next-parser (3.0.1.0)

gem list unparser

*** LOCAL GEMS ***

unparser (0.6.0)

java --version

openjdk 17 2021-09-14
OpenJDK Runtime Environment Homebrew (build 17+0)
OpenJDK 64-Bit Server VM Homebrew (build 17+0, mixed mode, sharing)

uname -v

Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64

https://bugs.ruby-lang.org/issues/15921

Hey @palkan first of all thanks for this awesome gem. I just started looking at it and I see you mention mruby in Readme so I wanted to try it out. I did ruby-next nextify --min-version=mruby tried also with a version specified after a dash but it gives me Malformed version number string mruby. It would be very useful if you could provide a list of all available versions and how to specify them in transpilation.

What did you do?

require 'ruby-next' doesn't work because of Thread::Backtrace::Location#label returns with the class name from Ruby 3.4.0dev.

      def build_location(trace_locations)
        # The caller_locations behaviour depends on implementaion,
        # e.g. in JRuby https://github.com/jruby/jruby/issues/6055
        while trace_locations.first.base_label != "patch"
          trace_locations.shift
        end

trace_locations is a result of caller_locations (Array) and each entries are Thread::Backtrace::Location.
From Ruby 3.4.0dev we changed the return value of #label method (https://bugs.ruby-lang.org/issues/19117).

on my environment

["/home/ko1/ruby/install/trunk/lib/ruby/gems/3.4.0+0/gems/ruby-next-core-1.0.1/lib/ruby-next/core.rb:128:in 'Class#new'",
 "/home/ko1/ruby/install/trunk/lib/ruby/gems/3.4.0+0/gems/ruby-next-core-1.0.1/lib/ruby-next/core.rb:128:in 'RubyNext::Core.patch'",
 "/home/ko1/ruby/install/trunk/lib/ruby/gems/3.4.0+0/gems/ruby-next-core-1.0.1/lib/ruby-next/core/kernel/then.rb:6:in '<top (required)>'",
 "<internal:/home/ko1/ruby/install/trunk/lib/ruby/3.4.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require'",
 "<internal:/home/ko1/ruby/install/trunk/lib/ruby/3.4.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require'"]

and #label returns RubyNext::Core.patch from Ruby 3.4.0dev.

To fix this issue, we simply need to use #base_label instead of #label.
(or use Regexp to match method name)

Now we are trying the new behavior of Thread::Backtrace::Location.
If you have further opinion about this specification, please comment on the redmine ticket.

What did you do?

Done nothing, no code or config changes done.

What did you expect to happen?

Expected to easily deploy a new image given that there is NO change set in the associated repository/code.

What actually happened?

Getting unknown errors involving below 2 main problems, thereby not enabling a normal deployment with the same code:

1. /usr/local/bundle/gems/ruby-next-core-1.0.0/lib/.rbnext/2.6/ruby-next/core/data.rb:5: warning: constant ::Data is deprecated
2. /usr/local/bundle/gems/redis-rack-3.0.0/lib/rack/session/redis.rb:8:in module:Session': uninitialized constant Rack::Session::Abstract::PersistedSecure (NameError)`

Additional context

Upon deploying the previously stable image of our code (as of 25 September 2023), the k8s pods are successfully running. But, we are stuck here because we aren't able to push new changes to our stable code as the same stable code only is now NOT able to provide a stable service upon trying out a fresh deployment.
Below is the error that we are getting, causing the associated K8s service pod in CrashLoopBackOff state:

Adding the same error in text form below:
/usr/local/bundle/gems/ruby-next-core-1.0.0/lib/.rbnext/2.6/ruby-next/core/data.rb:5: warning: constant ::Data is deprecated /usr/local/bundle/gems/ruby-next-core-1.0.0/lib/.rbnext/2.6/ruby-next/core/data.rb:5: warning: constant ::Data is deprecated /usr/local/bundle/gems/ruby-next-core-1.0.0/lib/.rbnext/2.6/ruby-next/core/data.rb:5: warning: constant ::Data is deprecated /usr/local/bundle/gems/redis-rack-3.0.0/lib/rack/session/redis.rb:8:inmodule:Session': uninitialized constant Rack::Session::Abstract::PersistedSecure (NameError)
Did you mean? Rack::Session::Abstract::Persisted
from /usr/local/bundle/gems/redis-rack-3.0.0/lib/rack/session/redis.rb:7:in <module:Rack>' from /usr/local/bundle/gems/redis-rack-3.0.0/lib/rack/session/redis.rb:6:in <top (required)>'
from /usr/local/bundle/gems/redis-rack-3.0.0/lib/redis-rack.rb:3:in require' from /usr/local/bundle/gems/redis-rack-3.0.0/lib/redis-rack.rb:3:in <top (required)>'
from /usr/local/bundle/gems/redis-actionpack-5.4.0/lib/action_dispatch/middleware/session/redis_store.rb:4:in require' from /usr/local/bundle/gems/redis-actionpack-5.4.0/lib/action_dispatch/middleware/session/redis_store.rb:4:in <top (required)>'
from /usr/local/bundle/gems/redis-actionpack-5.4.0/lib/redis-actionpack.rb:4:in require' from /usr/local/bundle/gems/redis-actionpack-5.4.0/lib/redis-actionpack.rb:4:in <top (required)>'
from /usr/local/bundle/gems/redis-rails-5.0.2/lib/redis-rails.rb:4:in require' from /usr/local/bundle/gems/redis-rails-5.0.2/lib/redis-rails.rb:4:in <top (required)>'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/runtime.rb:81:in require' from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/runtime.rb:81:in block (2 levels) in require'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/runtime.rb:76:in each' from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/runtime.rb:76:in block in require'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/runtime.rb:65:in each' from /usr/local/lib/ruby/site_ruby/2.5.0/bundler/runtime.rb:65:in require'
from /usr/local/lib/ruby/site_ruby/2.5.0/bundler.rb:114:in require' from /src/config/application.rb:7:in <top (required)>'
from /src/config/environment.rb:2:in require_relative' from /src/config/environment.rb:2:in <top (required)>'
from config.ru:3:in require_relative' from config.ru:3:in block in

Environment

Ruby version: 2.5.3

Ruby Next version: Unknown because we aren't directly using it via the Gemfile. It seems some other library is indirectly using it so we can't confirm the version.

Parser version: Unknown because we aren't directly using it via the Gemfile.

Unparser version: Unknown because we aren't directly using it via the Gemfile.

What did you do?

git clone https://github.com/kddnewton/syntax_tree.git
cd syntax_tree
git checkout cb72efc779aa8e9fdc812fc81b495c7998332f21
bundle

gem install ruby-next
ruby-next -V nextify ./lib

which shows:

RubyNext core strategy: refine
RubyNext transpile mode: rewrite
Remove old files: ./lib/.rbnext
Generated: ./lib/.rbnext/2.3/syntax_tree/basic_visitor.rb
Generated: ./lib/.rbnext/2.3/syntax_tree/cli.rb
Generated: ./lib/.rbnext/2.3/syntax_tree/formatter.rb
Generated: ./lib/.rbnext/2.7/syntax_tree/language_server/inlay_hints.rb
Generated: ./lib/.rbnext/2.7/syntax_tree/language_server.rb
Failed to transpile ./lib/syntax_tree/node.rb: SyntaxError — unexpected token tRBRACK

Additional Context

ruby-syntax-tree/syntax_tree#168

$ ruby -rparser/current -rbenchmark -e 'pp Parser::CurrentRuby.parse(File.read("./lib/syntax_tree/node.rb"))'

does work, so it seems parser can parse it.

Environment

Ruby version: I tried CRuby 3.0 and 3.1

Ruby Next version: 0.15.2

Parser version: 3.1.2.1

Unparser version: 0.6.5