Skip to content

Conversation

@sampersand
Copy link
Contributor

@sampersand sampersand commented Oct 17, 2025

This PR tweaks some of the Kernel conversion methods' signatures, as well as cleaning up/adding relevant tests.

Of particular note is that the numeric conversions (Integer/Float/Complex/Rational)'s final signature (the (untyped, ?exception: bool) -> type? one) now marks the exception: bool as required.

@sampersand sampersand force-pushed the sampersand/2025-10-17/update-conversion-methods branch from 666a86a to 1106b9c Compare October 17, 2025 22:25
Comment on lines +483 to +488
| (Numeric numeric, ?exception: bool) -> Complex
| (String real_or_both, ?exception: true) -> Complex
| (untyped real_or_both, exception: bool) -> Complex?
| (Numeric | String real, Numeric | String imag, ?exception: true) -> Complex
| (Numeric | String real, Integer | Float | Rational | Complex imag, exception: bool) -> Complex
| (Numeric | String real, untyped imag, exception: bool) -> Complex?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one's been changed because, after looking into it, Complex is quite messy:

  • Complex(Numeric) can never return nil, regardless of exception
  • Complex(Numeric | String, denom, exception: false) will actually return nil when the denom is a non-Integer | Float | Complex | Rational Numeric. Wonky, because exception: true/omitted doesn't do that, and it's only for the second argument

| (string str, int base, ?exception: true) -> Integer
| (string str, int base, exception: bool) -> Integer?
| (untyped, ?untyped, ?exception: bool) -> Integer?
| (untyped, ?int base, exception: bool) -> Integer?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If provided, the second argument actually has to be an int, otherwise an error will be thrown (regardless of exception)

Comment on lines +661 to +662
| (int | _ToR numer, int | _ToR denom, ?exception: true) -> Rational
| (int | _ToR numer, int | _ToR denom, exception: bool) -> Rational?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I simplified the signature of this a bit, collapsing the int | _ToR numer, ?... into the ones above it

Comment on lines +344 to +347
type.literal == val
rescue NoMethodError
raise if defined?(val.==)
false
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is needed because one of the Rational's signatures has a 1 in it, but is compared against a ToInt, which doesn't define ==.

errors = typecheck.method_call(method, method_type, trace, errors: [])

assert_empty errors.map {|x| RBS::Test::Errors.to_string(x) }, "Call trace does not match with given method type: #{trace.inspect}"
assert_empty errors.map {|x| RBS::Test::Errors.to_string(x) }, proc { "Call trace does not match with given method type: #{trace.inspect}" }
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of always creating the string for the traces, passing a proc in delays it until later. This is necessary because some of the Complex methods would be valid (eg Complex(1, Class.new(Numeric).new)), but the trace.inspect would end up calling #inspect on the resulting Complex, which raised an exception.

@sampersand sampersand marked this pull request as ready for review October 17, 2025 22:36
@sampersand sampersand force-pushed the sampersand/2025-10-17/update-conversion-methods branch from 1106b9c to 0772d0f Compare October 17, 2025 22:40
@sampersand sampersand force-pushed the sampersand/2025-10-17/update-conversion-methods branch from 0772d0f to c6706bd Compare October 17, 2025 22:45
@ksss
Copy link
Collaborator

ksss commented Oct 24, 2025

@sampersand
Thank you for your request.
However, due to the extensive number of changes, I am finding it difficult to review.
Would it be possible to split the changes into several Pull Requests?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants