These are chat archives for rust-lang/rust

17th
Apr 2019
Akos Vandra
@axos88
Apr 17 00:00

Can I tell the compiler to accept a move bind of the same variable into F and G, since only one of them will be executed?

    fn conditional_apply_result<V, E, F, G>(self, result: Result<V, E>, ifok: F, iferr: G) -> Self where F: FnOnce(Self, V) -> Self, G: FnOnce(Self, E) -> Self, Self: Sized {
        match result {
            Ok(v) => ifok(self, v),
            Err(e) => iferr(self, e)
        }
    }

e.g

  enum X { A, B };
  let x = X::A;

  let something = ....;

  something.conditional_apply_result(Ok(()), |something, ok| something.foo(x), |something, err| something.bar(x));
Mikail Bagishov
@MikailBag
Apr 17 08:37
In linux file will not be closed on exec() unless it has CLOEXEC (man fcntl) flag enabled
AFAIR std::io enables this flag by default when it opens files, socketc etc.
Michal 'vorner' Vaner
@vorner
Apr 17 09:05
axos88: Resources should generally be freed by that. And if it wasn't, fork won't help you. Forked process inherits mostly everything (with some exceptions).
Gwen Lofman
@glfmn
Apr 17 15:34

I have a project which succeeds to build on table but not on beta, something to do with

error: linking with `cc` failed: exit code: 1

I'm not sure where to start trying to fix this problem. It seems tcod-sys is failing to link to libtcod. The link error is very long but here is the first line:

/usr/bin/ld: /home/glfmn/Code/game/path_demo/target/debug/build/tcod-sys-6796d7a678fb5600/out/libtcod.a(sys_sdl_c.o): in function `TCOD_sys_load_font':
    /home/glfmn/.cargo/registry/src/github.com-1ecc6299db9ec823/tcod-sys-5.0.0/libtcod/src/sys_sdl_c.c:204: undefined reference to `SDL_FreeSurface'

Running cargo build on stable succeeds in the same repo for no reason I can discern.

How do I go about fixing this?
Cayle Sharrock
@CjS77
Apr 17 15:44
Hey guys, hopefully, this is a straightforward question. Is it possible to define the trait function definition for foo to allow slices if the associated type is array-like in the example below?
pub trait Foo {
    type P;
    // v--- How to define val's type to accept slices if P is arraylike
    fn foo(&self, val: &Self::P) -> u64; 
}

struct MyFoo(pub Vec<u8>);

impl MyFoo {
    fn new() -> MyFoo {
        MyFoo(Vec::new())
    }
}

impl Foo for MyFoo {
    type P = Vec<u8>;
    //             v--- How to define val's type to accept slices?
    fn foo(&self, val: &Vec<u8>) -> u64 {
        val[0] as u64 + self.0[0] as u64
    } 
}

fn main() {
    let mut f = MyFoo::new();
    f.0.push(5);
    let v = vec![1u8, 2, 3];
    assert_eq!(f.foo(&v), 6);
    // assert_eq!(f.foo(&v[1..]), 7);  --- Error! 
}
Ingvar Stepanyan
@RReverser
Apr 17 15:45
you need to define P as a slice instead
if you care only about them
Cayle Sharrock
@CjS77
Apr 17 15:45
P might not be arraylike though. I was thinking that AsRef or Deref might be the thing, but didn't quite get it right
Ingvar Stepanyan
@RReverser
Apr 17 15:46
What do you mean?
About "not be arraylike"?
You already seem to require that via Vec<u8>
I'm suggesting to just generalise it to any slice
Cayle Sharrock
@CjS77
Apr 17 15:46
Oh, you mean in the impl?
Ingvar Stepanyan
@RReverser
Apr 17 15:46
yeah
Cayle Sharrock
@CjS77
Apr 17 15:47
ah, ok. Let me try that
Ingvar Stepanyan
@RReverser
Apr 17 15:47
and you need to change type P; in the definition to type P: ?Sized; to allow unsized types
other than that it should work
Cayle Sharrock
@CjS77
Apr 17 15:49
Yup. 100%. Thanks, @RReverser
Ingvar Stepanyan
@RReverser
Apr 17 15:50
great :)
Georg Semmler
@weiznich
Apr 17 19:55
Is anyone out there that could me explain that this is sane? Or does it exploit some unspecified behavior?
Ichoran
@Ichoran
Apr 17 19:57
Without #[repr(C)] it's not specified, but it looks correct for C memory layout.
Of course the whole unsafe bit is not entirely sane :joy:
Georg Semmler
@weiznich
Apr 17 20:03
:see_no_evil:
Georg Semmler
@weiznich
Apr 17 22:24
Ok seems like this is not totally sound that way. #[repr(C)] does not grantee that the wrapper type has the same layout as the inner type, only that is conforms to the c memory layout. And that means for example primitive types like i32 are returned form functions in registers, whereas structs are returned on the stack.
Seems like there is #[repr(transparent)] that does exactly guarantee what I want :+1:
Ichoran
@Ichoran
Apr 17 23:13
Ah, okay, I thought you just meant the layout of a struct you were pointing at, not that you wanted the wrapper type to be unobservable.