Skip to content

feat[next]: Elementwise operations on Tuples - #2834

Open
SF-N wants to merge 7 commits into
sf_n_tracer_supportfrom
sf_n_tracer_support_element_wise
Open

feat[next]: Elementwise operations on Tuples#2834
SF-N wants to merge 7 commits into
sf_n_tracer_supportfrom
sf_n_tracer_support_element_wise

Conversation

@SF-N

@SF-N SF-N commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

No description provided.

tehrengruber and others added 4 commits August 27, 2026 19:44
The GTIR 'concat_where' type synthesizer derives the result dims via
'type_info.promote(tb, fb)', which asserted that the promoted dtypes are
'ScalarType'. A local field carries a 'ListType' dtype at the GTIR
level, so any 'concat_where' with a local-field branch failed with a
bare 'AssertionError' during type inference -- and it did so even though
both branches have the identical dtype, since the assertion is on the
dtype's kind, not on the operands differing.

Let 'promote' handle 'ListType' the same way it handles 'ScalarType':
both promote only between equal types, so the two cases collapse into a
single check. The docstring records that a 'ListType' only ever reaches
'promote' from the ITIR level, because the frontend represents the same
concept as a field with a local dimension in 'dims' and a scalar dtype.

The combination was previously untested ('test_concat_where.py' had no
local-dimension coverage), so the latent assert never fired in CI.
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