Adding an stdlib function suddenly uncovers a type inference error

[mikex-oss]

Describe the bug
After adding a new, totally unrelated stdlib function, I am getting a type inference error on an unrelated section of the std.x library.

xls/dslx/stdlib/std.x?l=1159:21-1159:22
1157: // of the symbol name to allow recursion.
1158: fn clzt_pow2_2(value: bits[2]) -> uN[2] {
1159:     const N_HALF = (2 >> 1) as s32;
~~~~~~~~~~~~~~~~~~~~~~~~~~^ TypeInferenceError: Could not infer a type for this number, please annotate a type.
1160:     combine_clzt_halfs(clzt_pow2_1(value[-N_HALF:]), clzt_pow2_1(value[:-N_HALF]))
1161: }

This is flagging an existing, untouched function:

xls/xls/dslx/stdlib/std.x

Line 1126 in 63a36e5

const N_HALF = (2 >> 1) as s32;

It appears this is indeed a type inference error. For example, if you write such a constant in a vacuous function, you will get the same error.

However, it has been happily passing CI since April when introduced in 506c62d.

Somehow the new function addition is surfacing the type inference error.

To Reproduce
Steps to reproduce the behavior:
This is a pretty weird repro:

1. bazel test //xls/dslx/stdlib:std_dslx_test. Should pass.
2. Add the following code somewhere above clzt_pow1_1 (referenced above):

// Splits the input bit vector into an array of N equal bit slices. Takes bits from LSB -> MSB.
fn split_bits<N: u32, IN: u32, OUT: u32 = {IN / N}>(x: bits[IN]) -> bits[OUT][N] {
    const_assert!(IN % N == u32:0);
    for (i, arr): (u32, bits[OUT][N]) in range(u32:0, N) {
        update(arr, i, x[i * OUT+:bits[OUT]])
    }(bits[OUT][N]:[bits[OUT]:0, ...])
}

#[test]
fn split_bits_one_element_test() {
    let x = u16:0x3210;
    let y = split_bits<u32:1>(x);
    assert_eq(y[0], u16:0x3210);
}

3. bazel test //xls/dslx/stdlib:std_dslx_test should fail with type inference error.

This is a somewhat fragile repro. The following will cause the type inference error to disappear again:

1. Remove the test.
2. Move this new code to the bottom of the file.
3. Change the new function to:

fn foo() -> u32 {
    42
}

#[test]
fn foo_test() {
    assert_eq(foo(), u32:42);
}

Expected behavior
The type inference error should have always been present, or it should never be present if this is legal syntax.

[hzeller]

(and in particular the specific version in std.x, I am about to add a work-around in there to circumvent the frontend instability)

[mikex-oss]

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 next_pow2(n: u32) -> u32 { upow(2, clog2(n)) }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ TypeInferenceError: Could not infer a type for this number, please annotate a type.