Skip to content

closure/FnMut type mismatch using box (HEAP) ... that does not occur with box ... #22043

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

Closed
pnkfelix opened this issue Feb 7, 2015 · 4 comments
Labels
A-type-system Area: Type system C-bug Category: This is a bug.

Comments

@pnkfelix
Copy link
Member

pnkfelix commented Feb 7, 2015

In the program below, using --cfg works1 or --cfg works2 both compile and run successfully, but --cfg breaks produces a type mismatch error.

Not clear on how to fix this or what is actually happening, but it might be blocking the placement overloaded-box desguaring work (rust-lang/rfcs#809)

#![feature(box_syntax)]

use std::cell::RefCell;

type BoxedFunc<'a> = Box<FnMut(&mut u32) -> &u32 + 'a>;
fn to_refcell<'a>(f: BoxedFunc<'a>) -> RefCell<BoxedFunc<'a>>
{
    RefCell::new(f)
}

#[cfg(works1)]
fn make_refcell() -> RefCell<BoxedFunc<'static>>
{
    to_refcell( box () |a:&mut u32| { *a = *a+1; a } )
}


#[cfg(works2)]
fn make_refcell() -> RefCell<BoxedFunc<'static>>
{
    to_refcell( box () |a:&mut u32| { *a = *a+1; a } )
}

#[cfg(breaks)]
fn make_refcell() -> RefCell<BoxedFunc<'static>>
{
    to_refcell( box (::std::boxed::HEAP) |a:&mut u32| { *a = *a+1; a } )
}

fn main() {
    let b = make_refcell();
    let mut a = 9;
    b.into_inner()(&mut a);

    assert_eq!(a, 10);
}

Transcript of error with --cfg breaks, from http://is.gd/NgHq2k :

<anon>:27:17: 27:71 error: type mismatch resolving `for<'r> <[closure <anon>:27:42: 27:71] as core::ops::FnMut<(&'r mut u32,)>>::Output == &'r u32`: values differ in mutability [E0271]
<anon>:27     to_refcell( box (::std::boxed::HEAP) |a:&mut u32| { *a = *a+1; a } )
                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<anon>:27:17: 27:71 note: required for the cast to the object type `for<'r> core::ops::FnMut(&'r mut u32) -> &'r u32`
<anon>:27     to_refcell( box (::std::boxed::HEAP) |a:&mut u32| { *a = *a+1; a } )
                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
playpen: application terminated with error code 101
@kmcallister kmcallister added the A-type-system Area: Type system label Feb 7, 2015
@steveklabnik
Copy link
Member

Triage: none of these work today, but I haven't followed the box syntax changes closely enough to know how to update them. Removing the type annotations on the closure arguments leads to

hello.rs:14:29: 14:30 error: unresolved name `a` [E0425]
hello.rs:14         to_refcell( box () |a| { *a = *a+1; a } )
                                        ^

which seems... quite bad.

@Mark-Simulacrum
Copy link
Member

Updated code, as best as I can figure. b still breaks with this error. I'm not sure why; I sort of thought that box was just sugar for in (::std::boxed::HEAP), but I guess that's not the case.

error[E0271]: type mismatch resolving `for<'r> <[[email protected]:13:31: 13:44] as std::ops::FnOnce<(&'r (),)>>::Output == &'r ()`
  --> test.rs:13:5
   |
13 |     in (::std::boxed::HEAP) { |b:&()| { b } }
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected bound lifetime parameter , found concrete lifetime
   |
   = note: concrete lifetime that was found is lifetime '_#5r
   = note: required for the cast to the object type `for<'r> std::ops::Fn(&'r ()) -> &'r ()`

error: aborting due to previous error
#![feature(box_syntax, box_heap)]
#![feature(placement_in_syntax)]

type BoxedFunc = Box<Fn(&()) -> &()>;

// works
fn a() -> BoxedFunc {
    box |a:&()| { a }
}

// breaks
fn b() -> BoxedFunc {
    in (::std::boxed::HEAP) { |b:&()| { b } }
}

fn main() {}

@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 22, 2017
@steveklabnik
Copy link
Member

Triage: as far as I know, everything about box syntax is going back to first base, right? I'm not sure if this issue is useful or not.

@bjorn3
Copy link
Member

bjorn3 commented May 15, 2022

Placement in syntax has been removed so this issue is no longer relevant I think.

@bjorn3 bjorn3 closed this as completed May 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

5 participants