Skip to content
This repository was archived by the owner on Jul 19, 2025. It is now read-only.

Conversation

sikachu
Copy link
Contributor

@sikachu sikachu commented Jan 19, 2015

The original type inference1 uses equal? which returns true when any subclass, including String, is passed in. This fixes an issue when a String type is mistakenly marked as Password type when passed in.

@sikachu sikachu force-pushed the fix-password-type branch 2 times, most recently from 1c3f132 to d4f075e Compare January 19, 2015 18:53
@brynary
Copy link
Member

brynary commented Jan 19, 2015

Can we get a test for this?

@sikachu
Copy link
Contributor Author

sikachu commented Jan 19, 2015

@brynary We sure can! Let me port this vague test case from codeclimate/codeclimate to here.

The original type inference[1] uses `equal?` which returns `true` when
any subclass, including `String`, is passed in. This fixes an issue when
a `String` type is mistakenly marked as `Password` type when passed in.

[1]: http://git.io/SXJanA
@sikachu
Copy link
Contributor Author

sikachu commented Jan 19, 2015

@brynary I've updated the PR with test. Let me know what you think.

@sikachu
Copy link
Contributor Author

sikachu commented Jan 20, 2015

As discussed in Slack, we'll roll out this change on codeclimate/codeclimate first, see if nothing breaks, then merge it.

marshally added a commit that referenced this pull request Jan 20, 2015
Fix type inference for Password type
@marshally marshally merged commit 954aafc into master Jan 20, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants