Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runtime error - Compiler is already declared as abstract. #1603

Open
xanderificnl opened this issue Aug 12, 2023 · 2 comments
Open

Runtime error - Compiler is already declared as abstract. #1603

xanderificnl opened this issue Aug 12, 2023 · 2 comments

Comments

@xanderificnl
Copy link

I encountered a RuntimeError: Tapioca::Dsl::Compiler is already declared as abstract, while setting up a local development environment. The issue first occurred while I was following Sorbet's guide and I've since reproduced the issue in a blank project with only a Gemfile that sources Tapioca.

Since the issue prevents tapioca from running, I assumed this was the appropriate repository. This might be an oversight on my part, but I'm hoping and grateful if someone could help me get back on track.

I've included the traceback and various details about my environment below.

an attempt at making the environment as clean as it possibly could be.
xander@X11:~/test$ bundle clean --force; gem clean; bundle install
Resolving dependencies...
Cleaning up installed gems...
Clean up complete
Fetching gem metadata from https://rubygems.org/.......
Resolving dependencies...
Bundle complete! 1 Gemfile dependency, 21 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
the RuntimeError causing Tapioca to fail, raised by sorbet-runtime.
xander@X11:~/test$ JRUBY_OPTS="--debug" bundle exec tapioca
bundler: failed to load command: tapioca (/home/xander/.asdf/installs/ruby/jruby-9.4.2.0/bin/tapioca)
RuntimeError: Tapioca::Dsl::Compiler is already declared as abstract
      declare_abstract at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/sorbet-runtime-0.5.10962/lib/types/private/abstract/declare.rb:10
             abstract! at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/sorbet-runtime-0.5.10962/lib/types/helpers.rb:21
      <class:Compiler> at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/tapioca-0.11.8/lib/tapioca/dsl/compiler.rb:17
          <module:Dsl> at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/tapioca-0.11.8/lib/tapioca/dsl/compiler.rb:6
      <module:Tapioca> at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/tapioca-0.11.8/lib/tapioca/dsl/compiler.rb:5
                <main> at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/tapioca-0.11.8/lib/tapioca/dsl/compiler.rb:4
               require at org/jruby/RubyKernel.java:1057
                <main> at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/tapioca-0.11.8/lib/tapioca/dsl.rb:15
               require at org/jruby/RubyKernel.java:1057
                <main> at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/tapioca-0.11.8/lib/tapioca/internal.rb:59
               require at org/jruby/RubyKernel.java:1057
      require_relative at org/jruby/RubyKernel.java:1084
                <main> at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/tapioca-0.11.8/exe/tapioca:23
                  load at org/jruby/RubyKernel.java:1091
                <main> at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/bin/tapioca:25
                  load at org/jruby/RubyKernel.java:1091
           kernel_load at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/bundler-2.4.18/lib/bundler/cli/exec.rb:58
                   run at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/bundler-2.4.18/lib/bundler/cli/exec.rb:23
                  exec at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/bundler-2.4.18/lib/bundler/cli.rb:492
                   run at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/bundler-2.4.18/lib/bundler/vendor/thor/lib/thor/command.rb:27
        invoke_command at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/bundler-2.4.18/lib/bundler/vendor/thor/lib/thor/invocation.rb:127
              dispatch at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/bundler-2.4.18/lib/bundler/vendor/thor/lib/thor.rb:392
              dispatch at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/bundler-2.4.18/lib/bundler/cli.rb:34
                 start at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/bundler-2.4.18/lib/bundler/vendor/thor/lib/thor/base.rb:485
                 start at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/bundler-2.4.18/lib/bundler/cli.rb:28
                <main> at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/bundler-2.4.18/exe/bundle:37
  with_friendly_errors at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/bundler-2.4.18/lib/bundler/friendly_errors.rb:117
                <main> at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/bundler-2.4.18/exe/bundle:29
                  load at org/jruby/RubyKernel.java:1091
                <main> at /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/bin/bundle:25
ASDF manages the tooling
xander@X11:~/test$ asdf --version
v0.12.0-816195d
OpenJDK 17 & jRuby that matches the production environment
xander@X11:~/test$ jruby --version
jruby 9.4.2.0 (3.1.0) 2023-03-08 90d2913fda OpenJDK 64-Bit Server VM 17.0.7+7 on 17.0.7+7 +jit [x86_64-linux]
Bundler
xander@X11:~/test$ bundle info tapioca
  * tapioca (0.11.8)
        Summary: A Ruby Interface file generator for gems, core types and the Ruby standard library
        Homepage: https://github.com/Shopify/tapioca
        Path: /home/xander/.asdf/installs/ruby/jruby-9.4.2.0/lib/ruby/gems/shared/gems/tapioca-0.11.8
xander@X11:~/test$ bundler config
Settings are listed in order of priority. The top value will be used.
xander@X11:~/test$ 
The Gemfile & the lock file
xander@X11:~/test$ cat Gemfile{,.lock}
# frozen_string_literal: true

source "https://rubygems.org"

group :development do
  gem 'tapioca', require: false 
end

# end Gemfile
GEM
  remote: https://rubygems.org/
  specs:
    ast (2.4.2)
    diff-lcs (1.5.0)
    erubi (1.12.0)
    netrc (0.11.0)
    parallel (1.23.0)
    parser (3.2.2.3)
      ast (~> 2.4.1)
      racc
    prettier_print (1.2.1)
    racc (1.7.1-java)
    rbi (0.0.17)
      ast
      parser (>= 3.0.0)
      sorbet-runtime (>= 0.5.9204)
      unparser (>= 0.5.6)
    sorbet (0.5.10962)
      sorbet-static (= 0.5.10962)
    sorbet-runtime (0.5.10962)
    sorbet-static (0.5.10962-java)
    sorbet-static-and-runtime (0.5.10962)
      sorbet (= 0.5.10962)
      sorbet-runtime (= 0.5.10962)
    spoom (1.2.3)
      erubi (>= 1.10.0)
      sorbet-static-and-runtime (>= 0.5.10187)
      syntax_tree (>= 6.1.1)
      thor (>= 0.19.2)
    syntax_tree (6.1.1)
      prettier_print (>= 1.2.0)
    tapioca (0.11.8)
      bundler (>= 2.2.25)
      netrc (>= 0.11.0)
      parallel (>= 1.21.0)
      rbi (~> 0.0.0, >= 0.0.16)
      sorbet-static-and-runtime (>= 0.5.10187)
      spoom (~> 1.2.0, >= 1.2.0)
      thor (>= 1.2.0)
      yard-sorbet
    thor (1.2.2)
    unparser (0.6.8)
      diff-lcs (~> 1.3)
      parser (>= 3.2.0)
    yard (0.9.34)
    yard-sorbet (0.8.1)
      sorbet-runtime (>= 0.5)
      yard (>= 0.9)

PLATFORMS
  universal-java-17

DEPENDENCIES
  tapioca

BUNDLED WITH
   2.4.18
@KaanOzkan
Copy link
Contributor

I'm not familiar with the jruby + bundler setup. Could something be loading tapioca twice?

@xanderificnl
Copy link
Author

I'm not familiar with the jruby + bundler setup. Could something be loading tapioca twice?

I have a suspicion that JRuby might be preloading the code, though I can't confirm this for certain. A somewhat nasty and makeshift edit to declare.rb substituting a raise with a return allowed me to workaround the issue, but I'm not recommending anyone else modify their local gem files. My intent is to keep digging a little bit further when I've got some spare time, but who knows when that'll be.

Any chance we could leave this issue open for a bit to see if anyone else has any insights? If it get stale, we can drop it as there's little/no interests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants