Inspection Bugs

Hey guys, thanks for the 1.1.1 release.  So far it is kicking some major arse!  So much so, that I turned on most of the Ruby Inspections.  That's how much I trust you guys

So, I searched for some of these bugs in the issue tracker and didn't find them.  You may be aware of some of them, but I'll post them here just in case (Still can't figure out how to get access to the bug tracker...):


1) "        Local variable can be uninitialized" incorrectly triggered.

A little known feature of Ruby:

if false
  local_variable = "unexpected!"
end
p local_variable

>> "nil"

That's right, variables defined in a non-executed block are defined but not set (they get a value of nil).

2) Instance variables in template files can't be found

Sometimes, RubyMine thinks my instance variables (@user, for example) are undefined in a template.  However, they are passed down from the controller.  Not sure what causes this.  Maybe setting them in application_controller?  Maybe from a before_filter?

3) Passing arguments to find, i.e. find( :condition => "whatever"), results in "Incorrect Call Argument Count"

4) Passing variables to partials, i.e. render(:partial => "side_bar", :dude => "awesome") results in "unexpected parameter value for Rails specific call"


That's all I've found so far.  Keep up the great work!

Thanks

Ross

7 comments

Ross,

Ditto on your comments and findings. I was about to report exactly the same problems. The "Incorrect Argument Call Count" especially seems to pop up in quite a few places bisides in find( :condition => "whatever").
Nevertheless, great job guys!

Once external API support is implemented as planned (in 1.5?), I think code-completion and inspection will be much more rock solid and extremely helpful.

Lev

0

Hello Ross,

At first thank you for constructive feedback =)

(Still can't figure out how to get access to the bug tracker...):




Go to "http://www.jetbrains.net/jira/browse/RUBY" press log link in right upper corner, than "signup" =)

1) "        Local variable can be uninitialized" incorrectly triggered.


A little known feature of Ruby:



if false
  local_variable = "unexpected!"
end
p local_variable


>> "nil"


That's right, variables defined in a non-executed block are defined but not set (they get a value of nil).

Ok, I've filled an issue - http://www.jetbrains.net/jira/browse/RUBY-4468

2) Instance variables in template files can't be found

Sometimes, RubyMine thinks my instance variables (@user, for example) are undefined in a template.  However, they are passed down from the controller.  Not sure what causes this.  Maybe setting them in application_controller?  Maybe from a before_filter?




In current implementation RubyMine only gather instance variables from view's action method. So it doesn't consider other instance variables. Please vote for http://www.jetbrains.net/jira/browse/RUBY-4470.

3) Passing arguments to find, i.e. find( :condition => "whatever"), results in "Incorrect Call Argument Count"




Cannot reproduce it. Probably RubyMine doesn't understand that your target object is Active::Record model. Please provide code example. Also check where RubyMine suggest to resolve "find" method and if it is available in autocompletion.

4) Passing variables to partials, i.e. render(:partial => "side_bar", :dude => "awesome") results in "unexpected parameter value for Rails specific call"




Does "render" accept any hash key here? Obviously RubyMine does't know about ":dude" key and warns about it. We can tell RubyMine that render should allow any key here but than RubyMine will not trigger on typos in valid hash keys, e.g :patrial instead of :partial

0

Ditto on your comments and findings. I was about to report exactly the same problems. The "Incorrect Argument Call Count" especially seems to pop up in quite a few places bisides in find( :condition => "whatever").

Please provide some code example. I trust you but I cannot reproduce. Probably we can tune our type inference a little to cover your use case.

Once external API support is implemented as planned (in 1.5?), I think code-completion and inspection will be much more rock solid and extremely helpful.

Were working on this in our internal RubyMine 1.5 builds. I think it should be iterative process. We've add in our trunk version some api to assigning return types to calls, assigning types to block variables, defining dynamic methods which will be visible in autocompletion.

Also some small piece of ruby API is available in RubyMine 1.1.1 and RubyMine 1.1 right now. You may add support for parameters completion for methods such as render, url_for, etc. E.g Ross may fix one magic line and his RubyMine will allow to use any key in "render" method without warning. Or RubyMine will provide completion for value of :dude hash key in render call. E.g. :dude may be one of "awesome" or "awful". Or you may improve behaviour of "Surround selection" feature (which converts selected text after pressing '[', '{', '#", etc. keys.
If you are interested in this a can provide some more detailed information.

0

Roman,

Thanks for replying.  Absolutely, I am interested in more detailed information on what you just described.  I would love to play with it and try it out.  Thanks,

Lev

PS  I will also try to dig out the actual examples of "Invalid Argument Call Count" from my project and post them  here later tonight.

0

Hey guys, thanks for the response!

I will sign up for the bug tracker post haste

So for the find example (3), I went back and noticed that it actually occurs when calling find from a method defined in a has_many declaration.  For example,

class User < ActiveRecord::Base
  has_many :messages do
    def public
      find(:all, :conditions => {:hidden => false})
    end
  end
end

Probably not as big a deal as I originally thought.

For the render partial example (4), yes you can pass any key to a partial to define a variable in that partial.  Like render(:partial => "message", :foo => "foo", :bar => "bar", :baz => "baz") etc.

I see what you're saying matching on the partial symbol and not the others though.

I would love to get my hands on the parts of the Ruby API you've implemented already!  Looking forward to that.

Thanks again!

Ross

0

Please sign in to leave a comment.