vec::IntoIter is now invariant

[asajeffrey]

#35447 replaced a *const T by a *mut T in IntoIter<T>, which changed IntoIter from being covariant to being invariant. This breaks crates like vec_map which relied on IntoIter being invariant, e.g. https://travis-ci.org/asajeffrey/presort/jobs/152720189#L208 has error:

error[E0308]: mismatched types
   --> /home/ajeffrey/.cargo/registry/src/github.heygears.com-1ecc6299db9ec823/vec_map-0.6.0/src/lib.rs:952:84
    |
952 |     fn into_iter_covariant<'a, T>(iter: IntoIter<&'static T>) -> IntoIter<&'a T> { iter }
    |                                                                                    ^^^^ lifetime mismatch
    |
    = note: expected type `IntoIter<&'a T>`
    = note:    found type `IntoIter<&'static T>`
note: the lifetime 'a as defined on the block at 952:81...
   --> /home/ajeffrey/.cargo/registry/src/github.heygears.com-1ecc6299db9ec823/vec_map-0.6.0/src/lib.rs:952:82
    |
952 |     fn into_iter_covariant<'a, T>(iter: IntoIter<&'static T>) -> IntoIter<&'a T> { iter }
    |                                                                                  ^^^^^^^^
    = note: ...does not necessarily outlive the static lifetime

   Compiling rustc-serialize v0.3.19
error: aborting due to previous error

cc @alexcrichton @frewsxcv @apasel422

[apasel422]

See my comment here: #35447 (comment)

[frewsxcv]

I'll be honest, I don't entirely know what covariant means, but I'm sorry for whatever pain it caused and wouldn't be offended if it got reverted.

Does anyone know of a resource explaining the terms 'covariant' and 'invariant' in this context?

[asajeffrey]

@frewsxcv the docs on variance are at https://doc.rust-lang.org/nomicon/subtyping.html

[apasel422]

@frewsxcv: Basically, we just need to change ptr: *mut T back to ptr: *const T.

[asajeffrey]

@apasel422 is it safe to do that without also removing as_mut_slice?

[frewsxcv]

We probably need something like this for IntoIter.

[apasel422]

@asajeffrey It seems to me that IntoIter<T> is logically a Vec<T>, so if Vec<T> is covariant in T and supports deref-ing to a mutable slice, then IntoIter<T> should also be OK to provide as_mut_slice.

[asajeffrey]

@apasel422 okay, good point. The thing that's worrying me is that the *const T is being treated as a constant pointer by LLVM, which may trigger unsafe LLVM optimizations it it's then exposed as a &mut[T].

[asajeffrey]

@apasel422 I think the difference is that Vec can be a Unique pointer, whereas IntoIter has two pointers into the vector, in order to be double-ended, so can't be Unique.

[apasel422]

@asajeffrey It's already safe to cast a *const T to a *mut T. The standard library does this all over the place, including in RawVec (which internally uses Unique), which is how Vec<T> is covariant in the first place.

In terms of duplicating Unique, yes, eventually Rust might make use of optimizations that indicate that the underlying pointer is globally unaliased, so we should probably use Shared here, or at the very least, something that isn't Unique (e.g. two *const Ts). I made a similar fix in #34608.

[asajeffrey]

@apasel422 okay, sounds like I'm being overly conservative!

[alexcrichton]

Thanks for the report @asajeffrey! As pointed out by @nikomatsakis we may just want to use Unique<T> here as well to have the correct variance just fall out.

@apasel422 or @frewsxcv, would either of you be interested in making a PR for this?

[alexcrichton]

Er Unique may not exactly be right, I think @apasel422 is correct here

[frewsxcv]

I can't do anything at this very moment, but if no one gets around to it after a few hours when I get home from work, I can look into it.

[frewsxcv]

@apasel422 just opened a PR to resolve this: #35733

Sorry again for the accidental invariance!