`N.pow(M)` returns zero, does not overflow for unsigned `N` and both `N` and `M` even (sometimes)

[cjsut]

Today I learned that eight to the power of eight is zero. Who'da thunk?

Incorrect:
2u8.pow(500) ➡️ 0 ❌
8u8.pow(8) ➡️ 0 ❌
4u32.pow(1000) ➡️ 0 ❌

Correct:
8u8.pow(7) ➡️ overflow ✅
8i8.pow(8) ➡️ overflow ✅
2u8.pow(9) ➡️ overflow ✅

Oddly enough, this one breaks the pattern:
2u8.pow(10) ➡️ overflow ✅

Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.

[eefriedman]

#28248 was supposed to fix this; looks like it missed the unsigned version?

[cjsut]

This playpen says that 8u8.pow(8) is 0 on nightly.

[eefriedman]

I meant that #28248 fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.

[porglezomp]

Could I take a stab at this?

[eefriedman]

Sure; feel free to ask if you have questions.

[porglezomp]

Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard #[should_panic] tests for overflow, but they seem to not panic even on cases that should right now.

[eefriedman]

Overflow checking in unit tests (#[test]) reflects whether the whole compiler was built in debug or release mode.

If you need to specify the overflow mode, you can use a separate test which explicitly specifies -C debug-assertions, like #28248.

[Mark-Simulacrum]

This has since been fixed, in #34942, which it looks like also added a test, so closing.