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:
- 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?)
- Railties Object extensions are a problem, I think!
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.