These are chat archives for rust-lang/rust

18th
Jan 2018
Patrick Elsen
@xfbs
Jan 18 2018 11:03
Hey everyone, I'm having some troubles with getting type constraints right.. How do I convince rust to let me do arithmetic? I'm getting borrow checker issues with this code:
Denis Lisov
@tanriol
Jan 18 2018 11:06
For example, you can limit the impl to T: Add<Output = T> + Copy
Patrick Elsen
@xfbs
Jan 18 2018 11:08
Ahhh Copy to the rescure! Merci Beaucoup!
Michal 'vorner' Vaner
@vorner
Jan 18 2018 13:06
Hello. I was wondering, mostly out of curiosity. I've read somewhere that rust's panic handling differs from C++ exceptions in that it's optimised not to happen ‒ eg. that panicking is more expensive, but not panicking is faster because it doesn't have to set up landing pads. But I've looked to the compiler code and it looked it talked about the same things as landing pads. Is the info about being faster on the usual case outdated, or is there some trick?
Michal 'vorner' Vaner
@vorner
Jan 18 2018 13:11
Yes. That's probably where I read about being optimised for not panicking. My question is how it is optimised for not panicking, compared to, for example, C++ exceptions (and if I get theoretical performance boost by using panic = "abort").
Because reading into the compiler it looked rust does basically the same as C++.
Patrick Elsen
@xfbs
Jan 18 2018 13:15
Well the way I understand it (am I'm a noob so I could be wrong) is that the general semantics of panic!() just abort your process — so no costs as in C++ to keep info on how to gracefully clean up. But then they also have std::panic::catch_unwind which catches a panic — probably worth digging into that code to find out how they accomplish that?
Ingvar Stepanyan
@RReverser
Jan 18 2018 13:26
@vorner Maybe what that article meant is that it Rust uses Result as opposed to throwing exceptions unless something goes really wrong?
Michal 'vorner' Vaner
@vorner
Jan 18 2018 14:16
Sigh. I'm not asking about that article. I know about when to panic and when to return Result, even quite few details about how the panic works internally. The question I ask is ‒ the handling of panic looks remarkably similar to how eg. gcc handles exceptions in C++. Which is in contrast with the statement in the article that claims rust paying lower cost for being ready to panic than other languages to throw/catch exceptions. I want to know if there's a specific trick how Rust does it differently than C++ or if that statement is outdated or wrong.
Steve Klabnik
@steveklabnik
Jan 18 2018 14:16
i have no idea if the claim is true or false, personally
given that we use libunwind, i'd be surprised if it was substantially different
when you don't set panic=abort, landing pads are certainly there
when you do, they're not
Michal 'vorner' Vaner
@vorner
Jan 18 2018 14:23
Thanks, that's what I was asking about, you confirmed what I though. I hoped a bit to be wrong ‒ because now we pay the performance price both for landing pads (in the default compilation settings) and checking what return value it was. Which is probably very small price, but it still gives C++ proponents some arguments (I was actually looking into this because of a discussion with someone who claimed he just can't use Rust because using Results is too slow ‒ you know, the kind of argument based on „really hard scientific data“).
Steve Klabnik
@steveklabnik
Jan 18 2018 14:24
heh
Michal 'vorner' Vaner
@vorner
Jan 18 2018 14:32
But it makes me wonder, if the stack could be unwinded without landing pads. If the program could find the return address into parent function, then it could look it up in some kind of emergency-cleanup table, pull specific code to clean up that frame stack and find another return address. The „normal“ code wouldn't have to care about anything at all, but the compiler would have to generate all these cleanup routines somehow, so it's probably too complex to warrant that effort.
Josh Holmer
@shssoichiro
Jan 18 2018 14:37
Hi, I'm having some trouble with type parameters. I have the following code: https://gist.github.com/shssoichiro/d09a2e3a23489208253fe36cad9a00bf and the line I'm having issue with is line 14. debug_query requires that my Backend::QueryBuilder implement Default, however I'm having difficulty representing this in my method signature. The syntax I have gives an "ambiguous associated type" error. If I change it to something like <Self::Backend as Connection::Backend>::QueryBuilder: Default, I get the error "cannot find associated type QueryBuilder in Connection::Backend" even though the type Backend has an associated type for QueryBuilder.
Denis Lisov
@tanriol
Jan 18 2018 20:01
@shssoichiro What trait is the QueryBuilder associated type defined in?
Leonora Tindall
@NoraCodes
Jan 18 2018 22:33
Can anyone give me some help with dynamic linking issues?
I'm working with libui and I have all my existing functions working, but I'm trying to add another function. It compiles but when I call it it segfaults, despite it existing in the loaded .so library. Any steps I can take to debug this? I've already looked at the disassembly in GDB
Josh Holmer
@shssoichiro
Jan 18 2018 22:36
@tanriol This is the Backend trait which includes the QueryBuilder associated type: http://docs.diesel.rs/diesel/backend/trait.Backend.html
Denis Lisov
@tanriol
Jan 18 2018 23:12
@shssoichiro Compiles for me with <Self::Backend as Backend>::QueryBuilder: Default
Josh Holmer
@shssoichiro
Jan 18 2018 23:21
Thanks! I had to move it to the impl instead of the fn definition and explicitly import the Backend type from diesel rather than using Connection::Backend. I guess that makes sense, I want to cast it to the trait rather than to the associated type.