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

Non copyable values captured by fn~ closures can be copied #2828

Closed
msullivan opened this issue Jul 7, 2012 · 4 comments
Closed

Non copyable values captured by fn~ closures can be copied #2828

msullivan opened this issue Jul 7, 2012 · 4 comments
Labels
A-typesystem Area: The type system
Milestone

Comments

@msullivan
Copy link
Contributor

The following program compiles and runs and will run the destructor twice:

class non_copyable {
    let n: int;
    new() { self.n = 0; }
    drop { log(error, "running destructor"); }
}

fn main() {
    let x = non_copyable();

    let f = fn~() { assert x.n == 0; };
    let g = copy f;

    f(); g();
}
@nikomatsakis
Copy link
Contributor

The problem is that send used to be a subset of copy. This was changed but it sounds like fn~ was changed inconsistently. If we moved over to the fn types with explicit bounds (fn:send vs fn:send copy) this would be solved.

@ghost ghost assigned catamorphism Nov 24, 2012
catamorphism added a commit that referenced this issue Dec 8, 2012
@catamorphism
Copy link
Contributor

This appears to have fixed itself, hallelujah! In 8255aa1 I checked in the test case.

@nikomatsakis
Copy link
Contributor

I don't think it's really fixed. If you modify the test case to include a "move" capture clause, it still reproduces:

struct NoCopy {
    n: int
}
fn NoCopy() -> NoCopy {
    NoCopy { n: 0 }
}

impl NoCopy: Drop {
    fn finalize(&self) {
        log(error, "running destructor");
    }
}

fn main() {
    let x = NoCopy();

    let f = fn~(move x) { assert x.n == 0; }; 
    let g = copy f; // <-- Error expected here

    f(); g();
}

The proper fix is the work on closure bounds I did not get to for 0.5!

@nikomatsakis nikomatsakis reopened this Dec 8, 2012
@catamorphism
Copy link
Contributor

Oops! Bumping to 0.6, then.

bors added a commit that referenced this issue Feb 7, 2013
RalfJung pushed a commit to RalfJung/rust that referenced this issue Apr 28, 2023
Tree Borrows: improved diagnostics

Better diagnostics for Tree Borrows violations.

- Shows where the conflicting tags (the one that was accessed and the one that had a permission or protector that caused UB) were reborrowed, which is more readable than only `<TAG>`
- Shows a small history of what happened for the faulty tag to get there (which lines caused it to lose read/write permissions)
- Explains permissions and transitions in natural language (e.g. "does not have read permissions" instead of "is Disabled")

Not perfect, but at least testing TB will be less confusing.

Lack of range information from `RangeMap` makes selection of relevant events nontrivial: we reconstruct history from knowledge of `(initial, final)` and `(offset, pi, p'i)` so that `initial -> final = p1 -> p1' = p2 -> p2' = p3 -> ... = final `
RalfJung pushed a commit to RalfJung/rust that referenced this issue Apr 30, 2023
Tree Borrows: improved diagnostics

Better diagnostics for Tree Borrows violations.

- Shows where the conflicting tags (the one that was accessed and the one that had a permission or protector that caused UB) were reborrowed, which is more readable than only `<TAG>`
- Shows a small history of what happened for the faulty tag to get there (which lines caused it to lose read/write permissions)
- Explains permissions and transitions in natural language (e.g. "does not have read permissions" instead of "is Disabled")

Not perfect, but at least testing TB will be less confusing.

Lack of range information from `RangeMap` makes selection of relevant events nontrivial: we reconstruct history from knowledge of `(initial, final)` and `(offset, pi, p'i)` so that `initial -> final = p1 -> p1' = p2 -> p2' = p3 -> ... = final `
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Update the CI to use MacOS 12 instead of MacOS 11. I'm leaving this as a
draft until I can validate that the bundle works on MacOS 11.

Resolves rust-lang#2827
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system
Projects
None yet
Development

No branches or pull requests

3 participants