Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Nondeterministic behavior when referencing a closure more than once #5783

Closed
bstrie opened this issue Apr 8, 2013 · 4 comments
Closed

Nondeterministic behavior when referencing a closure more than once #5783

bstrie opened this issue Apr 8, 2013 · 4 comments
Labels
A-lifetimes Area: Lifetimes / regions A-typesystem Area: The type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.

Comments

@bstrie
Copy link
Contributor

bstrie commented Apr 8, 2013

This program works as expected:

fn main() {
    let a = |x:int| { |y:int| -> int { x + y } };
    let b = a(2);
    //println(int::to_str(a(2)(3)));
    println(int::to_str(b(3)));  // 6
}

Uncomment that line and something goofy happens:

fn main() {
    let a = |x:int| { |y:int| -> int { x + y } };
    let b = a(2);
    println(int::to_str(a(2)(3)));  // 6
    println(int::to_str(b(3)));  // completely random number
}

The second print will be a different number every time it is run. This feels quite dangerous.

And if you try to use error!(b(3)), even in the first program, you get a segfault. But that might be a separate bug.

@bblum
Copy link
Contributor

bblum commented Jun 18, 2013

Can't reproduce. By default, this no longer typechecks, since the type of the second closure is inferred as a stack closure. If I annotate it, any combination of sigils that makes it compile seems to work properly.

Lightly modernized code as follows:

fn main() {
    let a: &fn(int) -> @fn(int) -> int = |x:int| |y:int| -> int x + y;
    let b = a(2);
    println(a(2)(3).to_str());  // 6
    println(b(3).to_str());  // completely random number
}

@bblum
Copy link
Contributor

bblum commented Jun 18, 2013

I expect @nikomatsakis might have fixed a bug in closure lifetime inference that recently fixed this bug?

@emberian
Copy link
Member

emberian commented Aug 5, 2013

Same. Needstest.

fhahn added a commit to fhahn/rust that referenced this issue Aug 27, 2013
bors added a commit that referenced this issue Aug 28, 2013
I've added a testcase, as mentioned in #5783
@huonw
Copy link
Member

huonw commented Sep 3, 2013

Closed by #8799.

@huonw huonw closed this as completed Sep 3, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 17, 2020
The "use .next()" replacement advice is on the last line of the code snippet,
where it is vulnerable to truncation. Display that advice at the beginning
instead.

closes rust-lang#5783
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 17, 2020
improve advice in iter_nth_zero

fixes rust-lang#5783

*Please keep the line below*
changelog:  For iter_nth_zero, the "use .next()" replacement advice is on the last line of the code snippet, where it is vulnerable to truncation. Display that advice at the beginning instead.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: Lifetimes / regions A-typesystem Area: The type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Projects
None yet
Development

No branches or pull requests

4 participants