…t, r=matthewjasper

Add future incompatibility lint for `array.into_iter()`

This is for rust-lang#65819. This lint warns when calling `into_iter` on an array directly. That's because today the method call resolves to `<&[T] as IntoIterator>::into_iter` but that would change when adding `IntoIterator` impls for arrays. This problem is discussed in detail in rust-lang#65819.

We still haven't decided how to proceed exactly, but it seems like adding a lint is a good idea regardless?

Also: this is the first time I implement a lint, so there are probably a lot of things I can improve. I used a different strategy than @scottmcm describes [here](rust-lang#65819 (comment)) since I already started implementing this before they commented.

### TODO

- [x] Decide if we want this lint -> apparently [we want](rust-lang#65819 (comment))
- [x] Open a lint-tracking-issue and add the correct issue number in the code -> rust-lang#66145

2259: Update smallvec and fix rustc warning r=matklad a=memoryruins

- Update smallvec in ra_mbe to [1.0](https://github.com/servo/rust-smallvec/releases/tag/v1.0.0)
- Heed rustc's `array_into_iter` lint rust-lang/rust#66145

Co-authored-by: memoryruins <[email protected]>

Such calls will likely create by-value iterators in the future.

See issue rust-lang/rust#66145.

Such calls will likely create by-value iterators in the future, and
raise warnings in 1.41.0 .

See issue rust-lang/rust#66145.

60: examples: use [T]::iter() rather than [T]::into_iter() r=davidor a=unleashed

Such calls will likely create by-value iterators in the future, and
raise warnings in 1.41.0 .

See issue rust-lang/rust#66145.

Co-authored-by: Alejandro Martinez Ruiz <[email protected]>

Such calls will likely create by-value iterators in the future, and
raise warnings in 1.41.0 .

See issue rust-lang/rust#66145.

rust-lang/rust#66145

This was previously accepted by the compiler but is being phased out;
it will become a hard error in a future rustc release.

See rust-lang/rust#66145
>

This was previously accepted by the compiler but is being phased out;
it will become a hard error in a future rustc release.

See rust-lang/rust#66145
>

…hewjasper

Generalize `array_into_iter` lint to also lint for boxed arrays

`Box` is special in that a method call on a box can move the value out
of the box. Thus, the same backwards-compatibility problem can arise
for boxed arrays as for simple arrays.

---

CC #66145
r? @matthewjasper  (as you reviewed the first PR)

`into_iter()` has been deprecated for arrays in 1.41 and replaced with
`iter()`. See rust-lang/rust#66145 .

Signed-off-by: Joshua Sorenson <[email protected]>

warning: this method call currently resolves to `<&[T; N] as IntoIterator>::into_iter` (due to autoref coercions), but that might change in the future when `IntoIterator` impls for arrays are added.
   --> src/entity/player.rs:363:11
    |
363 |         ].into_iter().enumerate() {
    |           ^^^^^^^^^ help: use `.iter()` instead of `.into_iter()` to avoid ambiguity: `iter`
    |
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #66145 <rust-lang/rust#66145>

…ange

See rust-lang/rust#66145 for details.

Change into_iter() to iter() in impl_zip_iter macro
to avoid the compliation warning related to
s://github.com/rust-lang/rust/issues/66145.

Change into_iter() to iter() in impl_zip_iter macro to avoid
the compliation warning related to the potentially upcoming
incompatibility with array.into_iter()
rust-lang/rust#66145.

Change into_iter() to iter() in impl_zip_iter macro
to avoid the compliation warning related to
s://github.com/rust-lang/rust/issues/66145.

475: Trait impls for tuples of arity <= 12 r=jswrenn a=jswrenn

I stopped at 12, because that's where libcore stops.

fixes #428
fixes #398

476: Undeprecate and optimize `fold_while` r=jswrenn a=jswrenn

Prompted by #469.

479: fix compiler warning on array.into_iter() r=jswrenn a=dmitris

Fix the compile warnings listed below by changing `into_iter()` invocation to `iter()` 
in the `impl_zip_iter` macro as recommended in rust-lang/rust#66145.
For additional background, see also rust-lang/rust#65819 and rust-lang/rust#66017 (the latter is the linter change producing the warning).

```
$ cargo build
   Compiling itertools v0.9.0 (/Users/dsavints/dev/hack/github.com/rust-itertools/itertools)
warning: this method call currently resolves to `<&[T; N] as IntoIterator>::into_iter` (due to autoref coercions), but that might change in the future when `IntoIterator` impls for arrays are added.
   --> src/ziptuple.rs:111:47
    |
111 |                 let size = *[$( $B.len(), )*].into_iter().min().unwrap();
    |                                               ^^^^^^^^^ help: use `.iter()` instead of `.into_iter()` to avoid ambiguity: `iter`
...
128 | impl_zip_iter!(A);
    | ------------------ in this macro invocation
    |
    = note: `#[warn(array_into_iter)]` on by default
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #66145 <rust-lang/rust#66145>
    = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

warning: this method call currently resolves to `<&[T; N] as IntoIterator>::into_iter` (due to autoref coercions), but that might change in the future when `IntoIterator` impls for arrays are added.
   --> src/ziptuple.rs:111:47
    |
111 |                 let size = *[$( $B.len(), )*].into_iter().min().unwrap();
    |                                               ^^^^^^^^^ help: use `.iter()` instead of `.into_iter()` to avoid ambiguity: `iter`
...
129 | impl_zip_iter!(A, B);
    | --------------------- in this macro invocation
    |
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #66145 <rust-lang/rust#66145>
    = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
```

Co-authored-by: Jack Wrenn <[email protected]>
Co-authored-by: Dmitry Savintsev <[email protected]>

As of Rust 1.48, array types do not actually implement IntoIterator, which
means that the borrow checker automatically introduces borrows with
surprising results. This behavior is now explicitly marked as unstable:

warning: this method call currently resolves to
`<&[T; N] as IntoIterator>::into_iter` (due to autoref coercions), but
that might change in the future when `IntoIterator` impls for arrays
are added.
warning: this was previously accepted by the compiler but is being
phased out; it will become a hard error in a future release!
note: for more information, see issue #66145
<rust-lang/rust#66145>

This commit changes the into_iter() calls into iter() calls that
match the current behavior in Rust.

Convert into_iter() calls into iter() where appropriate:
rust-lang/rust#66145

BUG=b:181674168
TEST=cargo test -p disk --features=composite-disk

Change-Id: I9c82a7b956598628010a3dbb33db6e425bbc4e2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/ /2743402
Tested-by: kokoro <noreply [email protected]>
Commit-Queue: Daniel Verkamp <[email protected]>
Reviewed-by: Dennis Kempin <[email protected]>
Reviewed-by: Dylan Reid <[email protected]>

This was lint's only purpose was to detect code that would break once
arrays would implement `IntoIterator`. Now that this impl exists, this
lint will never be triggered and thus is useless.

…into_iter)

e.g.:
warning: this method call currently resolves to `<&[T; N] as IntoIterator>::into_iter` (due to autoref coercions), but that might change in the future when `IntoIterator` impls for arrays are added.
  --> tests/serialize.rs:15:18
   |
15 |                 .into_iter()
   |                  ^^^^^^^^^ help: use `.iter()` instead of `.into_iter()` to avoid ambiguity: `iter`
   |
   = note: `#[warn(array_into_iter)]` on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #66145 <rust-lang/rust#66145>

…into_iter)

e.g.:
warning: this method call currently resolves to `<&[T; N] as IntoIterator>::into_iter` (due to autoref coercions), but that might change in the future when `IntoIterator` impls for arrays are added.
  --> tests/serialize.rs:15:18
   |
15 |                 .into_iter()
   |                  ^^^^^^^^^ help: use `.iter()` instead of `.into_iter()` to avoid ambiguity: `iter`
   |
   = note: `#[warn(array_into_iter)]` on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #66145 <rust-lang/rust#66145>

Point out that behavior might be switched on 2015 and 2018 too one day

Reword documentation to make it clear that behaviour can be switched on older editions too, one day in the future. It doesn't *have* to be switched, but I think it's good to have it as an option and re-evaluate it a few months/years down the line when e.g. the crates that showed up in crater were broken by different changes in the language already.

cc rust-lang#25725, rust-lang#65819, rust-lang#66145, rust-lang#84147 , and rust-lang#84133 (comment)

Point out that behavior might be switched on 2015 and 2018 too one day

Reword documentation to make it clear that behaviour can be switched on older editions too, one day in the future. It doesn't *have* to be switched, but I think it's good to have it as an option and re-evaluate it a few months/years down the line when e.g. the crates that showed up in crater were broken by different changes in the language already.

cc rust-lang#25725, rust-lang#65819, rust-lang#66145, rust-lang#84147 , and rust-lang#84133 (comment)

Point out that behavior might be switched on 2015 and 2018 too one day

Reword documentation to make it clear that behaviour can be switched on older editions too, one day in the future. It doesn't *have* to be switched, but I think it's good to have it as an option and re-evaluate it a few months/years down the line when e.g. the crates that showed up in crater were broken by different changes in the language already.

cc rust-lang#25725, rust-lang#65819, rust-lang#66145, rust-lang#84147 , and rust-lang#84133 (comment)

Point out that behavior might be switched on 2015 and 2018 too one day

Reword documentation to make it clear that behaviour can be switched on older editions too, one day in the future. It doesn't *have* to be switched, but I think it's good to have it as an option and re-evaluate it a few months/years down the line when e.g. the crates that showed up in crater were broken by different changes in the language already.

cc rust-lang#25725, rust-lang#65819, rust-lang#66145, rust-lang#84147 , and rust-lang#84133 (comment)

Point out that behavior might be switched on 2015 and 2018 too one day

Reword documentation to make it clear that behaviour can be switched on older editions too, one day in the future. It doesn't *have* to be switched, but I think it's good to have it as an option and re-evaluate it a few months/years down the line when e.g. the crates that showed up in crater were broken by different changes in the language already.

cc rust-lang#25725, rust-lang#65819, rust-lang#66145, rust-lang#84147 , and rust-lang#84133 (comment)

Point out that behavior might be switched on 2015 and 2018 too one day

Reword documentation to make it clear that behaviour can be switched on older editions too, one day in the future. It doesn't *have* to be switched, but I think it's good to have it as an option and re-evaluate it a few months/years down the line when e.g. the crates that showed up in crater were broken by different changes in the language already.

cc rust-lang#25725, rust-lang#65819, rust-lang#66145, rust-lang#84147 , and rust-lang#84133 (comment)

Point out that behavior might be switched on 2015 and 2018 too one day

Reword documentation to make it clear that behaviour can be switched on older editions too, one day in the future. It doesn't *have* to be switched, but I think it's good to have it as an option and re-evaluate it a few months/years down the line when e.g. the crates that showed up in crater were broken by different changes in the language already.

cc rust-lang#25725, rust-lang#65819, rust-lang#66145, rust-lang#84147 , and rust-lang#84133 (comment)

See rust-lang/rust#66145. The removed checks aren't particularly useful and
might turn into build errors in the next rust edition.

See rust-lang/rust#66145. The removed checks aren't particularly useful and
might turn into build errors in the next rust edition.

This fixes the following warning issued by rustc 1.41.0:

warning: this method call currently resolves to `<&[T; N] as IntoIterator>::into_iter` (due to autoref coercions), but that might change in the future when `IntoIterator` impls for arrays are added.
   --> src/lib.rs:921:55
    |
921 |         ["github:", "github topic:", "github issue:"].into_iter(),
    |                                                       ^^^^^^^^^ help: use `.iter()` instead of `.into_iter()` to avoid ambiguity: `iter`
    |
    = note: `#[warn(array_into_iter)]` on by default
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #66145 <rust-lang/rust#66145>