repeat expression do not honor lt bounds of copy

[lcnr]

#![feature(nll)]

#[derive(Clone)]
struct Foo<'a>(fn(&'a ()) -> &'a ());

impl Copy for Foo<'static> {}

fn mk_foo<'a>() -> Foo<'a> {
    println!("mk_foo");
    Foo(|x| x)
}

fn foo<'a>() -> [Foo<'a>; 100] {
    [mk_foo::<'a>(); 100]
}

fn main() {
    foo();
}

this compiles both with and without feature(nll). Note that mk_foo creates a value of type Foo<'a> which may not be copied.

Moving mk_foo::<'a>() into a local errors as expected:

#![feature(nll)]

#[derive(Clone)]
struct Foo<'a>(fn(&'a ()) -> &'a ());

impl Copy for Foo<'static> {}

fn mk_foo<'a>() -> Foo<'a> {
    println!("mk_foo");
    Foo(|x| x)
}

fn foo<'a>() -> [Foo<'a>; 100] {
    let x = mk_foo::<'a>();
    [x; 100]
}

this results in

error: lifetime may not live long enough
  --> src/main.rs:15:6
   |
13 | fn foo<'a>() -> [Foo<'a>; 100] {
   |        -- lifetime `'a` defined here
14 |     let x = mk_foo::<'a>();
15 |     [x; 100]
   |      ^ copying this value requires that `'a` must outlive `'static`

[lcnr]

considering that

fn pass<'a: 'a>(x: Foo<'a>) -> Foo<'a> {
    x
}

fn duplicate<'a>(x: Foo<'a>) -> [Foo<'a>; 100] {
    [pass::<'a>(x); 100]
}

also errors it seems like we somehow treat functions without any arguments in a special (and incorrect) way? @RalfJung I know that we've recently stabilized some additional exprs for repeat expressions, do you know more here?

[lcnr]

Ah no, we just decide whether to copy or move things depending on whether they implement Copy while ignoring regions. That kinda sucks :/

here's a version which duplicates Foo<'a> without it being copy

fn inner<'a, F: FnOnce() -> Foo<'a>>(f: F) -> [Foo<'a>; 2] {
    [f(); 2]
}

struct NeverCopy<T>(T);
impl<T> NeverCopy<T> {
    fn inner(self) -> T {
        self.0
    }
}

fn duplicate<'a>(foo: NeverCopy<Foo<'a>>) -> [Foo<'a>; 2] {
    inner(move || foo.inner())
}

but that isn't really too relevant considering that optionally Copyable types are apparently completely unusable anyways 😅

[RalfJung]

I think that is a general issue with Copy treatment also for other parts of MIR generation. But elsewhere we actually double-check and make sure to error if we later notice there was a mistake. Looks like for array repeat expressions we don't do that...

here's a version which duplicates Foo<'a> without it being copy

This looks exactly the same to me as the original example?

[RalfJung]

Cc @oli-obk @nikomatsakis who might know more about MIR generation and Copy. I agree this is a soundness issue...

[RalfJung]

Actually this might be a duplicate of #88901 ?

[oli-obk]

Yea it's probably a duplicate or variant of that issue.

This modulo-regions scheme is such a compiler footgun... I keep encountering it.

[lcnr]

This looks exactly the same to me as the original example?

The original code requires the creation of a new Foo while that example copies an existing one. My concern was that we somehow treat the function as if it were const, which isn't the case.

[nikomatsakis]

Yes, our general strategy for Copy is:

• Check (without respect to lifetimes) whether the type implements Copy;
• If so, generate a Copy;
• Enforce in MIR that the lifetime bounds hold.

If I had my druthers, we would have required that Copy impls were always applicable, but we did not, and so we opted for the above compromise (I could dredge up the issue, but it hardly matters). We do generally consider it a soundness issue to fail to enforce those rules.

(That said, I've been working on a revised type system that I think might make the whole "modulo-regions" scheme far less necessary or important... but that's for another time.)

[RalfJung]

Enforce in MIR that the lifetime bounds hold.

Yeah, that seems to not be working in some cases.

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-low