mikex-oss

This might not be the point of your example (since the returned `Y` could be replaced by `X`), but would it make sense to flag `fn p(y: uN[Y]) -> u32...

@richmckeever @meheff is this something we still want to leave open given `unroll_for!` from https://github.com/google/xls/issues/1387#issuecomment-2067090587 is resolved?

I found one scenario where `unroll_for!` is insufficient because the DSLX to IR conversion does not guarantee any ordering in the unrolled for. Take this contrived example: ``` import std;...

Note inline comments and blank lines (between comment and declaration, or between declarations) doesn't seem to workaround this issue.

I had to make a number of changes to the example in variant 1 due to valid compile errors but the following does now work after https://github.com/google/xls/commit/28b4476ed8712f4e31a43898cde0274a7b4ac81f: ``` import apfloat;...

Duplicate of #197

This no longer errors in TIv2 at build time, but as mentioned in the above comment, it still seems to fail in the bytecode interpreter at test runtime. `: internal...

Note that in addressing this, @hzeller also uncovered another latent type inference error at: ``` pub fn next_pow2(n: u32) -> u32 { upow(2, clog2(n)) } ``` ``` 1237: pub fn...

Maybe this is some hardware background leaking through, but that all seems fine... In SystemVerilog, you could have: ``` logic foo = 3'b001; logic bar[3] = '{1'b0, 1'b0, 1'b1}; ```...

Re-raising this as it's continued to be a regular mistake writing DSLX. Take the example of related bit vectors, one for data and one for valid: ``` data: bits[DATA_WIDTH][N] valid:...