pocke / rbs_rails

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Latest doesn't work with steep

jeromegn opened this issue · comments

I'm trying to use rbs_rails and steep together in a medium rails app and I'm experiencing some issues.

steep check will exit with a code of 1 without printing anything when using rbs_rails.

I've trimmed down the issue to:

That last item is weird, I don't quite know what's happening. I noticed there was no output with the generated activerecord.rbs file present. I then commented out definitions until I found what was wrong. If I comment out ActiveRecord::TestFixtures, things start working again.

However, steep complains with:

sig/rbs_rails/sig/generated/railties.rbs:4642:2...4642:36       UnknownTypeNameError: name=ActiveRecord::TestFixtures

This is expected. If I completely remove the class Object from railties.rb, I start getting no output again.

So I don't know what's wrong with this. Is it a rbs_rails issue or a steep issue? Maybe you have some insight.

Thanks for reporting this issue.

Could you try rbs validate command? It will explain more information when steep exits 1 silently.

$ rbs -Isig -rpathname -rlogger -rmutex_m validate

The -I option corresponds to Steepfile's signature, -r option corresponds to Steepfile's library.

After much fixing, I think I'm getting close.

$ rbs -Isig -rpathname -rlogger -rmutex_m validate
// ...
Traceback (most recent call last):
        18: from /home/jerome/.gem/ruby/2.6.4/bin/rbs:23:in `<main>'
        17: from /home/jerome/.gem/ruby/2.6.4/bin/rbs:23:in `load'
        16: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/exe/rbs:7:in `<top (required)>'
        15: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/cli.rb:92:in `run'
        14: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/cli.rb:392:in `run_validate'
        13: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/cli.rb:392:in `each_key'
        12: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/cli.rb:394:in `block in run_validate'
        11: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/definition_builder.rb:389:in `build_instance'
        10: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/definition_builder.rb:1011:in `try_cache'
         9: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/definition_builder.rb:394:in `block in build_instance'
         8: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/definition_builder.rb:282:in `instance_ancestors'
         7: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/definition_builder.rb:168:in `one_instance_ancestors'
         6: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/definition_builder.rb:225:in `mixin_ancestors'
         5: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/definition_builder.rb:225:in `each'
         4: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/definition_builder.rb:233:in `block in mixin_ancestors'
         3: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/ast/declarations.rb:122:in `each_mixin'
         2: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/ast/declarations.rb:122:in `each'
         1: from /home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/definition_builder.rb:237:in `block (2 levels) in mixin_ancestors'
/home/jerome/.gem/ruby/2.6.4/gems/rbs-0.7.0/lib/rbs/errors.rb:192:in `check!': sig/rbs_rails/sig/generated/railties.rbs:3569:6...3569:23: Could not find mixin: FileUtils (RBS::NoMixinFoundError)

I manually added https://github.com/pocke/rbs_rails/blob/master/sig/fileutils.rbs to my sig folder and now it validates.

#47
I've added FileUtils type in this pull request.
And I also fixed Steep's exit code problem soutaro/steep#171

So I think we can close this issue, is it right?

steep does not like that line: https://github.com/pocke/rbs_rails/blob/master/assets/sig/rails.rbs#L2 (maybe it's the overload on a class method?)

I'm not sure it is Steep's bug or not. But the overload syntax has been deprecated. ruby/rbs#342
So I'll replace the overload with ... even if it is not a bug. Thanks for the report!

We can close this issue yes, looks like this fixed everything.