transpile: Refactor binary operand handling and handle pointers/complex numbers - #1835
transpile: Refactor binary operand handling and handle pointers/complex numbers#1835Rua wants to merge 3 commits into
Conversation
b78f827 to
d93cde7
Compare
854e317 to
7efb825
Compare
Rua
changed the title
CBinOp::expected_operand_types and handle pointers/complex numbers
e62b79c to
85e05aa
Compare
d79be12 to
fa2af73
Compare
ahomescu
left a comment
ahomescu
left a comment
There was a problem hiding this comment.
Could you add a test or two for this (unit and/or snapshot)?
|
Not really sure what to test for, that isn't already tested? |
46b0ce9 to
31c8fbb
Compare
31c8fbb to
e5c1d4e
Compare
|
Okay we can land this as is since it's a pretty small change, but it would be nice in the future if changes were split between 1) refactorings (no tests needed), and 2) actual functional changes, that would need a test or two to handle those specific corner cases. |
| // See if a `Complex` version of the new result type exists. | ||
| if matches!(result_type_kind, CTypeKind::Complex(..)) { | ||
| let new_result_type_kind = | ||
| CTypeKind::Complex(result_type_id.ctype); |
There was a problem hiding this comment.
What if result_type_id is already a Complex? Would something like double f(double _Complex a, double _Complex b) { ... a + b ... } panic here? That could be a new test.
| } | ||
|
|
||
| // Add Rust fixed-size types. | ||
| for rust_type_kind in CTypeKind::PULLBACK_KINDS { |
There was a problem hiding this comment.
All the pullback types are integers, do any of them make sense for complex?
There was a problem hiding this comment.
They'd probably not be used much, but since C supports them, they probably ought to be here too.
2 participants
Both a refactor and a functional improvement. Complex numbers aren't supported yet, so I haven't included any tests for that, but this is needed to support them later.