"Duplicated declaration" after integrating rbs collection

[HoneyryderChuck]

I'm just enabling "rbs collection" in a project previously integrated with rbs. After doing rbs collection install, running rbs-enabled tests breaks on parsing sig files, on a static var which I know for sure ain't repeated:

# sig smth like this:

module A
  class B
    DEFAULT_VAR = String

> bundle exec rbs test --target "A::*" rspec
/home/.bundle/ruby/3.0.0/gems/rbs-1.8.1/lib/rbs/environment.rb:135:in `cache_name': /home/sig/jwt_token_kms/configuration.rbs:19:4...19:37: Duplicated declaration: ::A::B::DEFAULT_VAR (RBS::DuplicatedDeclarationError)
        from /home/.bundle/ruby/3.0.0/gems/rbs-1.8.1/lib/rbs/environment.rb:193:in `insert_decl'
        from /home/.bundle/ruby/3.0.0/gems/rbs-1.8.1/lib/rbs/environment.rb:177:in `block in insert_decl'
        from /home/.bundle/ruby/3.0.0/gems/rbs-1.8.1/lib/rbs/ast/declarations.rb:121:in `block in each_decl'
...

[pocke]

The definition looks loaded twice. I'm not sure why it is loaded twice, so could you make a small example to reproduce the problem?

By the way, perhaps rbs test command isn't aware of rbs collection. It is a bug. In cli.rb, it calls EnvironmentLoader#add_collection method to load RBSs from rbs_collection.lock.yaml, but rbs/test/setup.rb doesn't.

I'll fix the problem after releasing Ruby 3.1.

[joker1007]

I met a similar problem in Ruby 3.1.

I used rbs collection in a repository developing a rubygem.

In this situation, rbs collection detects the sig files of the developing gem, because bundler adds the gem to Gemfile.lock with gemspec.

But, steep detects the sig files by both Steepfile and rbs_collection.yaml and steep evaluates the sig files twice.

As a result of it, rbs raises DuplicatedDeclarationError, and type checking doesn't work.

I found a workaround to avoid this problem. It's to add the developing gem to the "ignore" section in rbs_collection.yaml

I'm not sure about the right behavior in such a situation, but the current behavior seems rather confusing.

Perhaps it would be more appropriate to treat it as a steep's issue.

[sadgb]

plus1 to this issue. @joker1007 thank you very much for workaround

[thearchduke]

I just ran into this as well. Thank you @joker1007 for what you found and shared. Can we get this added to the documentation? (Happy to open a PR, not sure if I'm welcome to)