Skip to content

rustc: Anonymous lifetimes within structs are refused too rigorously #12741

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
Florob opened this issue Mar 6, 2014 · 1 comment · Fixed by #18555
Closed

rustc: Anonymous lifetimes within structs are refused too rigorously #12741

Florob opened this issue Mar 6, 2014 · 1 comment · Fixed by #18555
Labels
A-lifetimes Area: Lifetimes / regions E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.

Comments

@Florob
Copy link
Contributor

Florob commented Mar 6, 2014

I have the following code:

#[deriving(Clone)]
pub struct Foo {
    priv f: fn(char, |char|)
}

impl Foo {
    fn bar(&self) {
        ((*self).f)('a', |c: char| { println!("{}", c); });
    }
}

fn bla(c: char, cb: |char|) {
    cb(c);
}

pub fn make_foo() -> Foo {
    Foo {
        f: bla
    }
}

fn main() {
    let a = make_foo();

    a.bar();
}

Which currently produces this error:

test.rs:3:10: 3:29 error: mismatched types: expected `fn(char, |char|)` but found `fn(char, |char|)` (expected concrete lifetime, but found bound lifetime parameter &)
test.rs:3     priv f: fn(char, |char|)
                   ^~~~~~~~~~~~~~~~~~~
note: expected concrete lifetime is lifetime ReInfer(ReVar(middle::ty::RegionVid{id: 22u}))
error: aborting due to previous error

This is apparently caused by the closure passed to the referenced function not having a lifetime.
IMHO this should be perfectly legal, because the struct does not actually reference the closure itself.

@ghost ghost added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Oct 30, 2014
@nikomatsakis
Copy link
Contributor

Dup of #10501 -- this was never fixed, but the corresponding check in the code was buggy

xFrednet pushed a commit to xFrednet/rust that referenced this issue May 5, 2024
…e-init, r=dswij

Don't lint assigning_clones on nested late init locals

Fixes rust-lang#12741

changelog: none
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-lifetimes Area: Lifetimes / regions E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants