Use 16-bit lengths on 16-bit targets

[kornelski]

This changes the internal length type from u32 to u16 on 16-bit targets. On 16-bit targets larger arrays won't be used, 32-bit arithmetic can be expensive, and 4 bytes is a significant overhead.

target_pointer_width is not going to be smaller than "16", so #[cfg(not(target_pointer_width = "16"))] is sufficient to mean > 16.

Rustup doesn't ship a 16-bit target by default, so unfortunately it's not easy to add a compile test for it, but the tests pass with u16 LenUint on larger platforms.

[tbu-]

Looks good to me, thanks!

[bluss]

Is this a breaking change, will need 0.8 or not?

[kornelski]

It's not a breaking change from the API perspective. The API and external types stay the same, only the internal representation changed, and only on 16-bit targets. Per hyrum's law somebody could be relying on particular values of sizeof or transmute, but I don't think these are promised by semver.

[tbu-]

This is not a breaking change AFAICT, because capacities greater than u16::MAX cannot be allocated on such machines anyway. This means that there will be a compile-time error for capacities larger than u16::MAX before and after this PR (on 16-bit platforms).

We change the underlying length integer which is not exposed and cannot be observed without mem::transmute or mem::size_of, but these kinds of changes do not count as breaking change (and it would be insane if they did — you couldn't change any private struct member).