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

Segfault with iterators and vector of borrowed structs #7573

Closed
catamorphism opened this issue Jul 3, 2013 · 1 comment
Closed

Segfault with iterators and vector of borrowed structs #7573

catamorphism opened this issue Jul 3, 2013 · 1 comment
Labels
A-lifetimes Area: lifetime related I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.

Comments

@catamorphism
Copy link
Contributor

The following code segfaults when run:

use std::io;

pub struct PkgId {
    local_path: ~str,
    junk: ~str
}

impl PkgId {
    fn new(s: &str) -> PkgId {
        PkgId {
            local_path: s.to_owned(),
            junk: ~"wutevs"
        }
    }
}

pub fn remove_package_from_database(id: &PkgId) {
    let mut lines_to_use: ~[&PkgId] = ~[];
    let push_id = |installed_id: &PkgId| {
        lines_to_use.push(installed_id);
    };
    list_database(push_id);

    for lines_to_use.iter().advance() |l| {
        io::stdout().write_line(l.local_path);
    }

}

pub fn list_database(f: &fn(&PkgId)) {
    let stuff = ["foo", "bar"];

    for stuff.iter().advance() |l| {
        f(&PkgId::new(*l));
    }
}

fn main() {
    remove_package_from_database(&PkgId::new("foo"));
}

This is with 040ac2a. It's suspicious to me that the compiler even accepts the ~[&PkgId] type (shouldn't the references need a lifetime?)

If I remove the junk field, or change io::stdout().write_line to io::println, then instead of a segfault I get a failure in the io library.

@catamorphism
Copy link
Contributor Author

Test fails correctly now. I'll check it in.

bors added a commit that referenced this issue Oct 6, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 3, 2021
Fix `option_if_let_else`

fixes: rust-lang#5822
fixes: rust-lang#6737
fixes: rust-lang#7567

The inference from rust-lang#6137 still exists so I'm not sure if this should be moved from the nursery. Before doing that though I'd almost want to see this split into two lints. One suggesting `map_or` and the other suggesting `map_or_else`.

`map_or_else` tends to have longer expressions for both branches so it doesn't end up much shorter than a match expression in practice. It also seems most people find it harder to read. `map_or` at least has the terseness benefit of being on one line most of the time, especially when the `None` branch is just a literal or path expression.

changelog: `break` and `continue` statments local to the would-be closure are allowed in `option_if_let_else`
changelog: don't lint in const contexts  in `option_if_let_else`
changelog: don't lint when yield expressions are used  in `option_if_let_else`
changelog: don't lint when the captures made by the would-be closure conflict with the other branch  in `option_if_let_else`
changelog: don't lint when a field of a local is used when the type could be pontentially moved from  in `option_if_let_else`
changelog: in some cases, don't lint when scrutinee expression conflicts with the captures of the would-be closure  in `option_if_let_else`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: lifetime related I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant