Rust update from 1.63 to 1.64 introduce lifetime problem on build

[Aboussejra]

Code

This is an attempt to reproduce a minimal example of a regression problem (backwards compatibility not assured) from a closed-source company codebase.

I tried this code: -> https://github.com/Aboussejra/rust_compiler_1.64_update_problem

pub struct VecNumber<'s> {
    pub vec_number: Vec<Number<'s>>,
    pub auxiliary_object: &'s Vec<usize>,
}

#[derive(Clone)]
pub struct Number<'s> {
    pub number: &'s usize,
}

impl<'s> VecNumber<'s> {
    pub fn vec_number_iterable_per_item_in_auxiliary_object(
        &self,
    ) -> impl Iterator<Item = (&'s usize, impl Iterator<Item = &Number<'s>> + Clone)> {
        self.auxiliary_object.iter().map(move |n| {
            let iter_number = self.vec_number.iter();
            (n, iter_number)
        })
    }
}

I expected to see the code building (This code is old and was building for years on rust 1.54, and builds on rust 1.63. the code works as intended in the proprietary codebase)

Instead, this happened:

error: lifetime may not live long enough
  --> src/main.rs:15:9
   |
11 |   impl<'s> VecNumber<'s> {
   |        -- lifetime `'s` defined here
12 |       pub fn vec_number_iterable_per_item_in_auxiliary_object(
13 |           &self,
   |           - let's call the lifetime of this reference `'1`
14 |       ) -> impl Iterator<Item = (&'s usize, impl Iterator<Item = &Number<'s>> + Clone)> {
15 | /         self.auxiliary_object.iter().map(move |n| {
16 | |             let iter_number = self.vec_number.iter();
17 | |             (n, iter_number)
18 | |         })
   | |__________^ associated function was supposed to return data with lifetime `'s` but it is returning data with lifetime `'1`

Version it worked on

It most recently worked on: 1.63 (from my repo, commit : 4c37cdc458abdecd0baf018500bbc0611bad568f)

rustc 1.63.0 (4b91a6ea7 2022-08-08)
binary: rustc
commit-hash: 4b91a6ea7258a947e59c6522cd5898e7c0a6a88f
commit-date: 2022-08-08
host: x86_64-unknown-linux-gnu
release: 1.63.0
LLVM version: 14.0.5

Version with regression

It does not work anymore on version 1.64: (from my repo, commit : 2728a5acdb645f93ef223a0bc15dd3545fd82c51)

rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: x86_64-unknown-linux-gnu
release: 1.64.0
LLVM version: 14.0.6

Backtrace

Including the backtrace by setting RUST_BACKTRACE=1 does not change anything to the error message.

I do not know why this problem occured though.

@rustbot modify labels: +regression-from-stable-to-{channel} -regression-untriaged -->

[Noratrieb]

searched nightlies: from nightly-2022-08-01 to nightly-2022-10-01 regressed nightly: nightly-2022-08-11 searched commit range: https://github.com/rust-lang/rust/compare/34a6cae28e7013ff0e640026a8e46f315426829d...29e4a9ee0253cd39e552a77f51f11f9a5f1c41e6 regressed commit: https://github.com/rust-lang/rust/commit/1603a70f82240ba2d27f72f964e36614d7620ad3

bisected with cargo-bisect-rustc v0.6.4

Host triple: x86_64-unknown-linux-gnu Reproduce with:

cargo bisect-rustc --access github --timeout 30 --start 2022-08-01 --end 2022-10-01 --regress error 

Out of the rollup, this was probably caused by #100340? @spastorino

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-critical

[spastorino]

Reopening to track backports.

[apiraino]

can this be closed? was #103205 backported to stable, right?

cc @spastorino @RalfJung (unsure who to ping)

[RalfJung]

I have no involvement with this whatsoever.^^ @Mark-Simulacrum is usually doing backports.

[pnkfelix]

#103205 was beta backported to 1.65, which is now released.

We won't be having a 1.64.1 release.

So this should be considered "fixed", since it is resolved on the current stable release of Rust.