Semantics of iterator core code

[dkcumming]

Currently our semantics does not support iterators. This can be largely broken down to two problems that we face currently:

• projection ordering issues seen in TransparentWrapper (maybe?);
• Insufficient implementation of BinOp::Offset which always points to a subslice in a collection and not a single element;

When iterating through a collection (or at least an array) the std library converts [T; N] to [std::mem::MaybeUninit<T>; N] via the into_iter() method. Below is std::mem::MaybeUninit and notice that field 0 represents uninit while field 1 represents value containing the T.

pub union MaybeUninit<T> {
    uninit: (),
    value: ManuallyDrop<T>,
}

Unions are transparent wrappers, in the sense that they are typed different but the they only store the data of T at the local and there is not change binary (e.g. alignment, offset, anything extra stored). The current implementation is designed for structs and only supports field access of 0 as that is the only field that is possible for a struct to be a transparent wrapper, however unions (like above) may have field access of 1. In the branch dc/WIP-union-transparent-wrapper I attempt to add the non-zero field access for unions in the transparent wrapper logic of TraverseProjection.

I am not sure if there is a projection ordering issue in the transparent wrapper logic, I think there might be. But currently it is hard to work with the problem as the wrong type is coming back from the pointer offset logic which always returns a subslice and never an index. After fixing that up things will be much clearer.