Skip to content

Conversation

@DeeveshChowdary
Copy link
Contributor

Hey team!

While looking into #3564, I tracked the bug down to the DSLX type inference for array literals. A range like 0..8 infers the narrowest bit width needed for its endpoints, and when I wrote let data: u32[8][2] = [0..8, 8..16]; the outer annotation only enforced the shape, not the inner element width. Because the type checker only propagated the annotated element type into top‑level literal numbers, the Range members kept their narrow widths, so data[0][0] wasn’t a u32 and the assertion failed with mismatched widths.

I fixed this by extending the existing propagation... when an array literal has an annotation, we now also push that annotated element type down into the start and end of any unannotated Range members (resolving through one level if the element type itself is an array). With the endpoints coerced to the target bits type, the Range deduces to the right element width and the nested array becomes u32[8][2] as annotated.

I added a regression test mirroring the original repro to lock in the behavior.

Thanks in advance for the review. Wishing everyone a bug free and relaxing holiday season!

Fixes: #3564

@DeeveshChowdary DeeveshChowdary changed the title Propagate annotated widths into range literals in nested arrays Propagate annotated widths into range literals in nested arrays (Re: #3564) Dec 21, 2025
@proppy proppy requested a review from richmckeever December 22, 2025 02:59
@proppy
Copy link
Member

proppy commented Dec 22, 2025

Thanks for tackling this!

// If the array type is annotated, as a user convenience, we propagate the
// element type to bare (unannotated) literal numbers contained in the
// array.
for (Expr* member : node->members()) {
Copy link
Member

Choose a reason for hiding this comment

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

@richmckeever should this do something similar and propagate over >1 dimension?

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.

bad type inference for range expression

2 participants