k:.Idx n doesn't make sense

[leissa]

My latest commit fixed some UB which materialized in the CI that this test here

ds2cps_ax_cps2ds_dependent2.thorin

failed to work sometimes on Windows.

Problem is: A literal 42:.Idx n doesn't make sense and should have been a type error (which it is now). It caused UB in some normalizers (which I have fixed).

One edge case is: 0:.Idx n. This kind of makes sense, as 0:.Idx 0 actually means 0:.Idx 2^64. So this literal is guaranteed to exist - but this is still kind of odd Oo Should we really allow that?

For now I disabled the test case above, as it makes use of this erroneous index.

See also #101, #105.

tl;dr:

• We need to fix ds2cps_ax_cps2ds_dependent2.thorin
• should we allow 0:.Idx n?

[NeuralCoder3]

A cast s2s/u2u should also fix the problem is probably the correct fix.

I think we should allow 0:.Idx n as it might be helpful to have a zero sometimes and it exists from a theoretical point of view.

[leissa]

@NeuralCoder3: can you fix the ds2cps_ax_cps2ds_dependent2.thorin test case? Then, I can close this one here already.