Another Yoke ICE with reference as capture argument

[sffc]

I'm filing this issue for @Manishearth to verify if it is a real bug, and if so, to open an issue against rust-lang.

@zbraniecki found another ICE when wiring up the Yoke project function:

thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `U3`,
 right: `U4`', compiler/rustc_mir/src/borrow_check/type_check/relate_tys.rs:86:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.56.0-nightly (0afc20860 2021-08-25) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [mir_borrowck] borrow-checking `datetime::<impl at components/datetime/src/datetime.rs:70:1: 286:2>::try_new::{closure#0}`
#1 [mir_borrowck] borrow-checking `datetime::<impl at components/datetime/src/datetime.rs:70:1: 286:2>::try_new`
end of query stack
warning: `icu_datetime` (lib) generated 14 warnings
error: could not compile `icu_datetime`; 14 warnings emitted

Instructions to reproduce:

1. Check out commit sffc@5e640c4
2. cd components/datetime
3. cargo +nightly-2021-08-27 run --example work_log --features std

The code in question is:

// `options` is an argument with type `&DateTimeFormatOptions`
let selected_pattern: DataPayload<'data, PatternFromPatternsV1Marker> = patterns_data
    .map_project_with_capture(options, |data, options, _| {
        PatternV1(
            data.get_pattern_for_options(options)
                .unwrap()
                .unwrap_or_default(),
        )
    });

I fixed the ICE in this code by changing the type of options from &DateTimeFormatOptions to DateTimeFormatOptions via cloning. So I think the compiler is confused about the lifetime of the capture if the capture is a reference.

[Manishearth]

I haven't tested this, but if it is an ICE it's always a compiler bug, and the only thing to be determined if it is fixed on the latest nightly or already has a bug filed

[sffc]

I haven't tested this, but if it is an ICE it's always a compiler bug, and the only thing to be determined if it is fixed on the latest nightly or already has a bug filed

Yes, and to reduce it. I tried reducing it but failed.

It occurs on the latest nightly.

[Manishearth]

@sffc I would still go ahead and file it, i can try to reduce it later. Often folks in the community will reduce it too.

[sffc]

Done: rust-lang/rust#88446

I'll close this issue since there is nothing left to do on our end for now.