Make ptr range iterable

[dtolnay]

This PR adds std::iter::Step impls for *const T and *mut T, enabling iteration over a range of pointers, such as produced by <[T]>::as_ptr_range and <[T]>::as_mut_ptr_range.

It is common for systems interacting with C++ to need to use pointer ranges for iteration, as begin/end pointer pairs are a design pattern in the C++ standard library.

// Designed to be called from C++ or C.
#[no_mangle]
unsafe extern "C" fn demo(start: *const u16, end: *const u16) {
    for ptr in start..end {
        println!("{}", *ptr);
    }
}

fn main() {
    let slice = &[1u16, 2, 3];
    let range = slice.as_ptr_range();
    unsafe { demo(range.start, range.end); }
}

[rust-highfive]

r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

[leonardo-m]

Isn't it better to convert the pair of pointers coming from C or C++ into something like a slice, for Rust usage? What do you need all those pointers for in Rust code?

[kennytm]

If end - start does not wholly divide size_of::<T>(), its forward may never hit end. In particular it will crash with `Step` invariants not upheld in case like:

let start = !1 as *const [u8; 2];
let end = !0 as *const [u8; 2];
(start..end).next();

[dtolnay]

@leonardo-m:

Isn't it better to convert the pair of pointers coming from C or C++ into something like a slice, for Rust usage?

In FFI, I definitely don't think so. Materializing a reference (to a slice, or even to individual elements) is more prone to UB in Rust than directly working with the foreign pointers as pointers. One basically has to be an expert in Rust aliasing rules, which are not necessarily cogently written down at this point yet, in order to do it correctly. Whereas someone with basic C++ knowledge can write the pointer-based code and have it be correct.

Compare:

let start: *mut T = ...;
let end: *mut T = ...;
for ptr in start..end {
    // Only the preconditions of the C++ callee come into play, which a C++ dev
    // is already going to be comfortable reasoning about. Nothing about stacked
    // borrows, concurrency, initializedness, inhabitedness, alignedness, or other
    // Rust-isms is relevant.
    unsafe { cpp(ptr); }
}

let mut slice = std::slice::from_raw_parts_mut(...); // suddenly a pile of extremely subtle
                                                     // invariants in order for this to be allowed
for elem in slice {
    unsafe { cpp(elem as *mut T); } // probably UB
}

[dtolnay]

@kennytm:

If end - start does not wholly divide size_of::<T>(), its forward may never hit end. In particular it will crash with `Step` invariants not upheld

Good call. Hopefully this is fixable within the constraints of the Step trait design. The mental model I want for the behavior of the iterator is that beginT..endT produces the same sequence of numeric values as (beginT as usize..endT as usize).step_by(size_of::<T>()).

[dtolnay]

`Step` invariants not upheld

It turns out the desired semantics for pointer ranges is incompatible with the current requirements of Step, so I've opened #91000 with a different approach. Closing this PR in favor of that one.