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
Partial support for is_a?
with exhaustiveness
#781
Labels
Comments
jez
added
bug
Something isn't working
unconfirmed
This issue has not yet been confirmed by the Sorbet team
good first issue
Good for newcomers
and removed
unconfirmed
This issue has not yet been confirmed by the Sorbet team
labels
Jun 8, 2019
jez
added a commit
that referenced
this issue
Jul 16, 2021
I took a stab at trying to fix #4358 but stalled out on it. The approach I took was to attempt to just use whether the flow-sensitive call was on a `<cfgAlias>` variable (only created by `cfg::Alias` instructions). The problems I ran into were: - Using only names wasn't powerful enough to see through static-fields. The only way to properly handle static fields would be to maintain a mapping of whether the alias that initialized a `<cfgAlias>` was actually a static-field symbol or not. - I would have been fine with that, because it would have made some of the bugs go away, just not all of them. The next problem was that changing *only* `updateKnowledge` was not enough. For any of these methods (`Kernel#is_a?`, `Module#===`, `Module#<=`), if they have an intrinsic that computes the result type to be `TrueClass` or `FalseClass` exactly (not `T::Boolean`), that also introduces the same dead code error. So to fix the dead code error, you need to fix **both** the case in `updateKnowledge` and the intrinsic for that method. At the time of writing, only `Module#===` has such an intrinsic, but honestly, I'd rather **add** intrinsics for `is_a?` / `<=` (to fix this bug: #781) than I would like to figure out how to fix the existing ones. Basically: adding a halfway-working solution here would make it harder to fix #781 in the future, and I don't want that.
jez
added a commit
that referenced
this issue
Jul 16, 2021
I took a stab at trying to fix #4358 but stalled out on it. The approach I took was to attempt to just use whether the flow-sensitive call was on a `<cfgAlias>` variable (only created by `cfg::Alias` instructions). The problems I ran into were: - Using only names wasn't powerful enough to see through static-fields. The only way to properly handle static fields would be to maintain a mapping of whether the alias that initialized a `<cfgAlias>` was actually a static-field symbol or not. - I would have been fine with that, because it would have made some of the bugs go away, just not all of them. The next problem was that changing *only* `updateKnowledge` was not enough. For any of these methods (`Kernel#is_a?`, `Module#===`, `Module#<=`), if they have an intrinsic that computes the result type to be `TrueClass` or `FalseClass` exactly (not `T::Boolean`), that also introduces the same dead code error. So to fix the dead code error, you need to fix **both** the case in `updateKnowledge` and the intrinsic for that method. At the time of writing, only `Module#===` has such an intrinsic, but honestly, I'd rather **add** intrinsics for `is_a?` / `<=` (to fix this bug: #781) than I would like to figure out how to fix the existing ones. Basically: adding a halfway-working solution here would make it harder to fix #781 in the future, and I don't want that.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Input
→ View on sorbet.run
Observed output
Expected behavior
Since we've exhausted all the cases, it should be fine to return from this method (the inferred method return type should not include
NilClass
.This can be solved the same way as #59 (see #743).
The text was updated successfully, but these errors were encountered: