Parametric signedness bit type doesn't work

[mikex-oss]

Describe the bug
The bytecode emitter errors out if you try to use a return type like xN[RESULT_SIGNED][RESULT_SZ].

: INVALID_ARGUMENT: Provided status is not in recognized error form: INTERNAL: Bits-to-array cast bit counts must match. Saw 32 vs 0.; while evaluating: to_int<u32:8, u32:23, u32:32>(APFloat<u32:8, u32:23> { sign: u1:0, bexp: u8:0x0, fraction: u23:0x0 })
...
Error: INTERNAL: Bits-to-array cast bit counts must match. Saw 32 vs 0.; while evaluating: ...
=== Source Location Trace: ===

To Reproduce
Steps to reproduce the behavior:
Change this line:

xls/xls/dslx/stdlib/apfloat.x

Line 1301 in 69f00f9

(x: APFloat<EXP_SZ, FRACTION_SZ>) -> bits[RESULT_SZ] {

to xN[RESULT_SIGNED][RESULT_SZ] (updating the casts at

xls/xls/dslx/stdlib/apfloat.x

Line 1352 in 69f00f9

result as bits[RESULT_SZ]

and

xls/xls/dslx/stdlib/apfloat.x

Line 1355 in 69f00f9

result as bits[RESULT_SZ]

)

Expected behavior
This should properly include parameterized signedness and remove the need to cast the result in the wrapper at

xls/xls/dslx/stdlib/apfloat.x

Line 1370 in 69f00f9

to_signed_or_unsigned_int<RESULT_SZ, true>(x) as sN[RESULT_SZ]

[mikex-oss]

@proppy suggested this undocumented feature, pointing to 9761efb.

Once fixed, it would also be good to document it at https://google.github.io/xls/dslx_reference/#bit-type. xN is referenced in a couple places, but it's not clear this is not just a convenience shorthand for documentation.

[cdleary]

Note this test case exhibits the same problem:

#[test]
fn casts() {
    assert_eq(s1:1, u1:1 as xN[true][1]);
    assert_eq(u1:1, s1:1 as xN[false][1]);
}

#[test]
fn widening_casts() {
    assert_eq(s2:0b11, s1:1 as xN[true][2]);
    assert_eq(u2:0b01, u1:1 as xN[false][2]);

    assert_eq(s2:0b11, xN[true][1]:1 as s2);
    assert_eq(u2:0b11, xN[false][1]:1 as u2);
}