Unboxed closures: Type inferencer failed to detect closure argument types

#![feature(unboxed_closures)]
#![feature(overloaded_calls)]

fn action<T: Send, F: FnOnce(Sender<T>) -> ()>(sender: Sender<T>, cb: F) {
  cb(sender);
}

pub fn main() {
  let (tx, rx) = channel();

  // Must be uncommented to work    vvv
  action(tx, move |:tx /* :Sender<&'static str> */| {
      tx.send("zomg")
  });

  println!("recv: {}", rx.recv());
}

Output:

rustc fnonce.rs
fnonce.rs:13:7: 13:22 error: the type of this value must be known in this context
fnonce.rs:13       tx.send("zomg")
                   ^~~~~~~~~~~~~~~
fnonce.rs:12:3: 12:9 error: type mismatch: the type `closure` implements the trait `core::ops::FnOnce<([type error]),[type error]>`, but the trait `core::ops::FnOnce<(sync::comm::Sender<<generic #9>>),()>` is required (expected struct sync::comm::Sender, found type error)
fnonce.rs:12   action(tx, move |:tx /* :Sender<&'static str> */| {
               ^~~~~~
fnonce.rs:12:3: 12:9 note: the trait `core::ops::FnOnce` must be implemented because it is required by `action`
fnonce.rs:12   action(tx, move |:tx /* :Sender<&'static str> */| {
               ^~~~~~
error: aborting due to 2 previous errors

cc me.

I think that we may be able to make this inference work more uniformly using the new trait infrastructure. In principle, trying to match the Fn vs FnMut etc traits against the closure type ought to inform the type of its arguments. There are some challenges here, though.

@pcwalton

cc @pcwalton

I was recently running into a similar issue and chalked it up to what I was working on. cc me.

Another case, I am unsure if it is related or not, but I had code that was working, wrapped the FnOnce argument w/ Option and the type inferencer could not figure it out.

#![feature(unboxed_closures)]
#![feature(overloaded_calls)]

fn action<T, F: FnOnce(Option<T>)>(val: T, cb: F) {
    cb(Some(val));
}

pub fn main() {
    let (tx, rx) = channel::<&'static str>();

    //     Required for compiling     vv
    action("zomg", |:v: /* Option<&'static str> */| tx.send(v.unwrap()));
    assert_eq!(rx.recv(), "zomg");

    println!("Done");
}

An almost minimal test:

#![feature(unboxed_closures)]
fn doit<T, F: Fn(T)>(val: T, f: F) { f.call((val,)); }
fn doit_boxed<T>(val: T, f: |T|) { f(val); }
pub fn main() {
    doit_boxed(0i, |x| { x.to_int(); });
    doit(0i, |&: x/*: int*/| { x.to_int(); });
}

error:

<anon>:6:32: 6:42 error: the type of this value must be known in this context
<anon>:6     doit(0i, |&: x/*: int*/| { x.to_int(); });
                                        ^~~~~~~~~~
<anon>:6:5: 6:9 error: type mismatch: the type `closure` implements the trait `core::ops::Fn<([type error]),[type error]>`, but the trait `core::ops::Fn<(int),()>` is required (expected int, found type error)
<anon>:6     doit(0i, |&: x/*: int*/| { x.to_int(); });
             ^~~~
<anon>:6:5: 6:9 note: the trait `core::ops::Fn` must be implemented because it is required by `doit`
<anon>:6     doit(0i, |&: x/*: int*/| { x.to_int(); });
             ^~~~
error: aborting due to 2 previous errors

Seems related to the method syntax (and thus maybe AutoDeref).

Tackling this next.

You can also see tests in https://github.com/TeXitoi/rust-mdo/tree/unboxed-closure

I think this was fixed by PR #19089, at least for the most part. Open if you disagree.

Auto merge of rust-lang#17907 - ChayimFriedman2:no-once_cell, r=Veykril

fix: `double_comparisons` suggestion dropping required parentheses (#…

Navigation Menu

Repository navigation

Unboxed closures: Type inferencer failed to detect closure argument types #17907

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Unboxed closures: Type inferencer failed to detect closure argument types #17907

Description

Activity

nikomatsakis commented on Oct 10, 2014

nikomatsakis commented on Oct 10, 2014

jroesch commented on Oct 10, 2014

carllerche commented on Oct 14, 2014

TeXitoi commented on Oct 22, 2014

nikomatsakis commented on Nov 18, 2014

TeXitoi commented on Nov 18, 2014

nikomatsakis commented on Dec 15, 2014

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions