Lighter-weight support for Uint concat, split operations

[andrewwhitehead]

This also moves EncodedUint <-> [u8; N] conversion out of the macro rules for different Uint sizes. The Concat, Split, and SplitMixed traits are changed to define the output types only, while the ConcatMixed trait is removed as unnecessary. In all, this seems to have a positive effect on build times. New tests are added to ensure that result types can be inferred when it is useful.

Related to #1095

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.24%. Comparing base (5b5f80b) to head (8bbe5f5).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1191      +/-   ##
==========================================
+ Coverage   86.93%   87.24%   +0.31%     
==========================================
  Files         182      182              
  Lines       20528    20561      +33     
==========================================
+ Hits        17845    17939      +94     
+ Misses       2683     2622      -61     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tarcieri]

Nice! Getting rid of the Concat/ConcatMixed split (I was just going to try a default Rhs parameter for ConcatMixed which gives Concat behavior) was definitely one of the last things I wanted to get addressed before the release, and this seems one better. Especially love anything that brings down compile times, because they're pretty bad right now.

[andrewwhitehead]

I also had a shot at using typenum, but it seems there's currently no way to resolve a unique Const<T> from an Unsigned instance, ie. the reverse of ToUInt. I think that's what would be needed to bind the sum or difference of two input parameters as a const usize.

[andrewwhitehead]

Hmm, it looks like this would also be a breaking change for crypto-primes.

[tarcieri]

I have another breaking change cued up as it were: #1189

I'd also like to remove the legacy nlimbs! macro.

cc @fjarri

[andrewwhitehead]

I've done some testing with a new typenum-like crate which allows the removal of impl_uint_concat_split_mixed and impl_uint_concat_split_even entirely. For me that gets the compilation time down to 1.4s, and presumably allows a lot more integer types to be defined, but it would require changing these traits a little bit because split() can't effectively infer the half-size limb count with the traits as they are here. I think this update could be future-proofed to allow a future removal of the macros without changing the public API, and allowing users to generically call split() and concat() while checking the appropriate bounds. Probably something like this:

impl<const LIMBS: usize> Uint<LIMBS> {
  pub const fn split<const HALF_LIMBS: usize>(&self) -> (Uint<HALF_LIMBS>, Uint<HALF_LIMBS>)
  where Self: SplitEven<Output=Uint<HALF_LIMBS>>;
  
  pub const fn split_mixed<const LO_LIMBS: usize, const HI_LIMBS: usize>(&self) -> (Uint<LO_LIMBS>, Uint<HI_LIMBS>)
  where Self: Split<LO_LIMBS, Output=Uint<HI_LIMBS>>;

  pub const fn concat<const WIDE_LIMBS: usize>(&self, hi: &Uint<LIMBS>) -> Uint<WIDE_LIMBS>
  where Self: Concat<LIMBS, Output=Uint<WIDE_LIMBS>>;
  
  pub const fn concat_mixed<const HI_LIMBS, const WIDE_LIMBS: usize>(&self, hi: &Uint<HI_LIMBS>) -> Uint<WIDE_LIMBS>
  where Self: Concat<HI_LIMBS, Output=Uint<WIDE_LIMBS>>;
}

[tarcieri]

@andrewwhitehead why'd you set this back to draft? (I mean, it seems to have conflicts, but...)

[andrewwhitehead]

I'd like to modify the traits a bit, so they wouldn't need to be changed again (hopefully) and are a bit easier to use.

[tarcieri]

I'd be curious if there's a way to unify something like this with ArrayEncoding but I'll leave that for a followup.