Has unsoundness in a major, safe interface.

The main utility for Vec can reuse an allocation of differing element size
thus violating the explicit requirements of Vec::from_raw_parts and in
particular the allocator contract, potentially leading to memory corruption
on drop of the resulting Vec.

The interface affected are (maybe not complete):

• MapVecInPlace::map
• MapVecInPlace::map_in_place
• MapVecInPlace::filter_map
• MapVecInPlace::filter_map_in_place

An analysis of the code to show the issue:

In a macro, this code checks for various size and alignment constraints on
deciding whether to execute an in-place branch or a fallback (that may panic
in some variants).

unsafe {
if size!($a) == 0 || size!($b) == 0 {
$zero
} else if align!($a) != align!($b) {
$alignment
} else if $f(size!($a),size!($b)) {
$incompatible
} else {
$ok
}
}

Already a naming issue appears, as the $incompatible branch is actually
taken when f returns true and some instantiation has |a,b| a==b as this
argument. Consequently, the incompatible parameter is filled with the
in-place branch in the fallback branch where the parameter is $ok:expr

Note that the check for map is |a,b| a%b==0 and it invokes $fallback
with the $ok:expr argument set to map_vec(self, f) (note: the f here is
from the parameters of map). The map_vec function is an unsafe function
eventually doing the equivalent of

let (ptr, len, cap) = /* The obvious */;
// Some transformation code on raw.
Vec::from_raw_parts(ptr, len, cap)

This violates very clearly the contract which states:

ptr's T needs to have the same size and alignment as it was allocated with