-
Notifications
You must be signed in to change notification settings - Fork 89
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
Steep doesn't handle Object#present? correctly #472
Comments
@mtsmfm Hi. Sorry for cutting in, but my understanding is that I don't think it is easy to solve this problem. Steep has special support for some methods, a feature called logic. steep/lib/steep/type_inference/logic_type_interpreter.rb Lines 16 to 30 in 89d42e0
steep/lib/steep/ast/types/factory.rb Lines 385 to 435 in 89d42e0
In order to solve this problem, |
As far as I know rbs doesn't have any specification of narrowing on control flow. I think what we need is user defined type guard on rbs. https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates |
Bumping this. The (rather confusing and minimal) readme seems to indicate that using current_assignment = Assignment.
find_by(merchant_id: self.merchant_id) # this returns [ Assignment | nil ]
return if current_assignment.nil? # steep doesn't seem to realize that this narrows down to Assignment
# @type var current_assignment: Assignment
errors.add(:base, "#{current_assignment.merchant.name} is already assigned!") Leaving out the
Putting it in gets a different error:
|
This issue is a game-stopper for any code that uses ActiveSupport. |
To represent methods like `Object#blank?` and `Object#present?` in ActiveSupport, this adds method annotations `primitive:nil?` and `primitive:not_nil?`. They will be considered as same as `nil?` and not `nil?` internally. refs: soutaro#472
Full demo: https://github.com/mtsmfm/steep-with-present
Is it intentional?
I think it should behave like
if a
.The text was updated successfully, but these errors were encountered: