Skip to content

Closure inference fails to infer that move is required when pattern matching #30046

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
nikomatsakis opened this issue Nov 25, 2015 · 6 comments
Closed
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-type-system Area: Type system C-bug Category: This is a bug. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. P-medium Medium priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

See this example, which fails to compile:

fn foo<F>(f: F)
    where F: FnOnce()
{
}

fn main() {
    let x = Some(vec![1, 2, 3]);
    foo(|| {
        match x {
            Some(y) => { }
            None => { }
        }
    });
}

Error:

<anon>:9:15: 9:16 error: cannot move out of captured outer variable in an `FnOnce` closure
<anon>:9         match x {
                       ^
<anon>:10:18: 10:19 note: attempting to move value to here
<anon>:10             Some(y) => { }
                           ^
<anon>:10:18: 10:19 help: to prevent the move, use `ref y` or `ref mut y` to capture value by reference
error: aborting due to previous error
playpen: application terminated with error code 101
@nikomatsakis nikomatsakis added A-type-system Area: Type system I-wrong T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 25, 2015
@nikomatsakis
Copy link
Contributor Author

triage: P-medium

@rust-highfive rust-highfive added the P-medium Medium priority label Nov 25, 2015
@durka
Copy link
Contributor

durka commented Nov 25, 2015

A-const-fn?

@durka
Copy link
Contributor

durka commented Nov 25, 2015

Do you just mean the help message is wrong, or it should have automatically created a move closure?

@nikomatsakis
Copy link
Contributor Author

@durka neither. Normally, even for non-move closures, we infer when particular variables are used in the body and we move just those variables. For some reason, that is not triggering in this particular case.

@nagisa
Copy link
Member

nagisa commented Jan 29, 2016

Might be duplicate of #26139?

@brson brson added the E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. label Aug 25, 2016
@nikomatsakis
Copy link
Contributor Author

Related example from #26139:

struct Name(String);

fn apply<F>(f: F) where
    F: FnOnce() {

    f()
}

fn main() {
    let n = Name(String::new());
    let consume = || {
        let Name(i) = n;
    };

    apply(consume);
}

@Mark-Simulacrum Mark-Simulacrum added C-bug Category: This is a bug. and removed I-wrong labels Jul 24, 2017
bors added a commit that referenced this issue Nov 12, 2017
…ures, r=eddyb

adjust closure kind based on the guarantor's upvar note

Fixes #30046.

r? @eddyb
@RalfJung RalfJung added the A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) label Dec 1, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-type-system Area: Type system C-bug Category: This is a bug. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. P-medium Medium priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants