Regression 1.66 "some_fn::{opaque#0}<'_> does not live long enough"

[Dav1dde]

Code

Unfortunately I couldn't minimize it further without using a dependency (code can be executed online here):

/*
[dependencies]
sycamore = "0.8.2"
web-sys = "0.3"

*/

use sycamore::prelude::{Scope, View, Html, DomNode, ReadSignal, GenericNode};

pub fn create_toggle_bool<'a>(cx: Scope<'a>, initial: bool) -> (&'a ReadSignal<bool>, impl Fn() + Copy + 'a) {
    // let open = sycamore::prelude::create_signal(cx, false);
    // let open_toggle = || open.set(!*open.get());
    // (open, open_toggle)
    (todo!(), || {})
}

pub fn Foo<G: Html>(cx: Scope) -> View<G> {
    let (open, open_toggle) = create_toggle_bool(cx, false);

    // Uncomment these 2 lines to make it compile (moved out of the function)
    // let open = sycamore::prelude::create_signal(cx, false);
    // let open_toggle = || open.set(!*open.get());

    let a = move |_: web_sys::Event| open_toggle();

    move || {
        let __el = DomNode::text_node("test");
        ::sycamore::generic_node::GenericNode::event(&__el, cx, "click", a);
        __el;
    };

    todo!()
}

fn main() {
}

• GenericNode
• DomNode#event
• My failed attempt to reduce it further

The code compiles and runs with 1.66 but fails with 1.67:

error: `create_toggle_bool::{opaque#0}<'_>` does not live long enough
  --> src/main.rs:28:9
   |
28 |         ::sycamore::generic_node::GenericNode::event(&__el, cx, "click", a);
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I expect this code to still compile on 1.67

Version it worked on

1.66

Version with regression

1.67

rustc 1.67.0 (fc594f156 2023-01-24)
binary: rustc
commit-hash: fc594f15669680fa70d255faec3ca3fb507c3405
commit-date: 2023-01-24
host: x86_64-unknown-linux-gnu
release: 1.67.0
LLVM version: 15.0.6

[Teapot4195]

searched nightlies: from nightly-2022-09-15 to nightly-2022-10-15
regressed nightly: nightly-2022-09-26
searched commit range: 3f83906...f5193a9
regressed commit: f5193a9

bisected with cargo-bisect-rustc v0.6.5

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

cargo bisect-rustc --end=2022-10-15 

@rustbot label -E-needs-bisection

[clubby789]

Minimized to:

use std::marker::PhantomData;
#[derive(Clone, Copy)]
pub struct Scope<'a>(&'a PhantomData<&'a mut &'a ()>);
fn event<'a, F: FnMut() + 'a>(_: Scope<'a>, _: F) {}
fn make_fn<'a>(_: Scope<'a>) -> impl Fn() + Copy + 'a {
    || {}
}

fn foo(cx: Scope) {
    let open_toggle = make_fn(cx);

    || event(cx, open_toggle);
}

fn main() {}

@rustbot label -E-needs-mcve

[clubby789]

This is a breaking change but it is a necessary soundness fix

#95474

[Noratrieb]

Since the crater run there found no regressions I'm gonna @oli-obk anyways but I don't think there's anything to do here.

[oli-obk]

Yea, this is expected breakage. We should improve the diagnostic though.

[Dav1dde]

Is the reduced example unsound?

I would expect let open_toggle = make_fn(cx); to behave the same as let open_toggle = || {};, is this assumption wrong?

[Noratrieb]

The minimized example is not really unsound as in it doesn't contain UB - it doesn't do anything. But the feature that it uses is unsound. Such is the fate of a safe language, it often has "false positives".

[Dav1dde]

Thanks, but this is a bit advanced for me still, but if this is expected I can close the issue or do you want me to keep it open for better diagnostics?

[steffahn]

On my machine the original post as well as the reduced example regress in 1.66, not 1.67. Can someone confirm or deny this? If that’s true, than the title here would be misleading.

[oli-obk]

Godbolt agrees, this regressed in 1.66

[steffahn]

I only looked at this issue, because there’s been a thread on URLO on a similarly-looking issue that appears to actually regress on 1.67: #107516

Mentioning it here, because it might be of interest to readers of this thread :-)

[Dav1dde]

This is weird, this only broke on my CI because it was pinned to stable (-> 1.67), my local machine was still compiling and running the code fine on 1.66. Maybe the reduced example already regressed in 1.66 but my corner case only regresses in 1.67?

[aliemjay]

This regression can indeed be mitigated (cc #108691), at least for the MCVE we have.
@rustbot label -A-diagonstics regression-from-stable-to-stable

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium