These are chat archives for rust-lang/rust

25th
Apr 2019
Kelly Thomas Kline
@kellytk
Apr 25 01:02
@chisa0a I don't see a solution presented. What am I missing?
chisana
@chisa0a
Apr 25 01:04
idk, was the first search result
search engines are cool that way @kellytk
Kelly Thomas Kline
@kellytk
Apr 25 01:06
Whatever silly point you're trying to make is irrelevant to the fact that the link doesn't appear to include a solution
chisana
@chisa0a
Apr 25 01:06
if you say so :)
chisana
@chisa0a
Apr 25 01:13
@kellytk maybe this section of the rust-book will be more helpful: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#overriding-dependencies
Kelly Thomas Kline
@kellytk
Apr 25 01:23
That page is where I got the idea to try the package key which didn't solve the issue
chisana
@chisa0a
Apr 25 01:25
keep trying stuff, hunch is patch is probably what you want. somewhat new to Rust myself
if you have control of one of the dependency versions, try wildcard or some of the other options that will cover both versions present in you project and dependencies
Vineel Kovvuri
@vineelkovvuri
Apr 25 08:31

Hi I am new to Rust, I have following question,

why is str a type level thing (so called dynamically-sized type - DST) not a library defined struct?

  1. Why cannot it be made a standard std struct which has a pointer and length.
  2. And make &str a normal reference instead of a fat pointer holding the above details....
Denis Lisov
@tanriol
Apr 25 08:46
@vineelkovvuri Not as simple, but yes, &str could be StringSlice instead. The compiler would still need to know about it (it needs to know what's the type of a string literal), but that could be done. Would it be better... that's a different question :-)
Making str itself a pointer-length struct is an extra unnecessary indirection.
...and a pretty limiting indirection - for example, you would not be able to return a subslice as &MyStr because MyStr has to be allocated somewhere.
Zakarum
@omni-viral
Apr 25 10:15
str could be defined as struct str([u8]);
But yeah, it would have to be lang item for string literals
@vineelkovvuri How would you disambiguate mutable string slice from shared?
If &str would be StringSlice then &mut str would be StringSliceMut
Then how Deref for String would work?
Zakarum
@omni-viral
Apr 25 10:20
impl Deref for String {
  type Target = StringSlice;
  fn deref(&self) -> &StringSlice {} // Unnecessary indirection.
}

impl DerefMut for String {
  fn deref_mut(&mut self) -> &mut StringSlice {} // Uh, oh, but I need mutabale slice.
}
Definding str as newtype over [u8] would work, it still will be DST, and it still would have to be lang item. So it is not far from builtin type we have now
Superstring.ch
@SUSYLABS
Apr 25 11:48
error[E0283]: type annotations required: cannot resolve [u8]: std::convert::AsRef<_>
--> ethcore/private-tx/src/lib.rs:275:21
|
275 | keccak(&state_buf.as_ref())
I can compile before updating rust, need some help here
Denis Lisov
@tanriol
Apr 25 11:52
What is this keccak?
Superstring.ch
@SUSYLABS
Apr 25 11:52
it is a crypto library in parity
sha3
Denis Lisov
@tanriol
Apr 25 11:59
"updating Rust" - stable or nightly?
Superstring.ch
@SUSYLABS
Apr 25 12:04
stable
cargo 1.34.0 (6789d8a0a 2019-04-01)
Denis Lisov
@tanriol
Apr 25 12:18
The master branch builds for me with the same version without any problems.
Georg Semmler
@weiznich
Apr 25 17:56

I'm back with another ABI related question. I'm playing a bit with wasm now and I'm asking myself: Is there any difference (ABI wise) between exporting a function like this:

#[no_mangle]
pub fn length(ptr: u32, length:u32) -> u32 {
 // stuff here to get length of the passed "string"
}

or this:

#[no_mangle]
pub fn length((ptr, length): (u32, u32)) -> u32 {
 // stuff here to get length of the passed "string"
}

Both variants seem to work fine when I try to use the produced wasm binary in wasmer like this. Also looking at the corresponding example via godbolt it seems like both functions are called the same way.
Now my question is: Is this implementation defined behavior which should not be relied on, or is it OK to build something on top of that?

Zakarum
@omni-viral
Apr 25 18:33
@weiznich My guts tell me this is implementation defined
If, for example, implementation will decide that components of the tuple should be stored in reverse order
Georg Semmler
@weiznich
Apr 25 18:38
Right, probably this will break as soon as some field reorder mechanism gets in place.
:disappointed: That means I need to find another solution for my problem… (Basically my idea was to somehow "guess" the types for the ffi function signature from the pure rust one. Unfortunately there is no 1:1 mapping there so I cannot simply say a: A::RawType, b: B::RawType and so on. Using tuples would have simplified that a lot. Now it seems like I need to teach the proc macro at least something about those types :()
Zakarum
@omni-viral
Apr 25 19:06
You can try (u32, u64, u32) for example. I wonder if u64 goes first
Kevin Stenerson
@kestred
Apr 25 19:33

I'm stubbing my toe on an expected opaque type, found a different opaque type problem, and hoping someone with a sharp eye will know whats what!

As far as I understand, this error should come up when a function returning an opaque type has conflicting returns?
--- but in these functions there should be exactly one return type, and I don't have a good intuition on what the cause might be...

pub fn statement() -> impl PredictiveGrammar {
    ( never()
    | expression_statement()
    | declaration()  // <--- error occurs here
    )
}

pub fn expression_statement() -> impl PredictiveGrammar {
    ( expression()
    , token(SEMI)
    ).commit(EXPRESSION_STATEMENT)
}

pub fn declaration() -> impl PredictiveGrammar {
    ( never()
    | variable_declaration()
    )
}

Any thoughts?

Kevin Stenerson
@kestred
Apr 25 19:39
With some impl
impl<Err, L, R> BitOr<R> for Either<Err, L, R>
where
    Err: ParseError,
    L: PredictiveGrammar<Err>,
    R: PredictiveGrammar<Err>,
{
    type Output = Either<Err, Self, R>;
    fn bitor(self, rhs: R) -> Self::Output { self.or(rhs) }
}
Ah... nevermind! I see now :sweat_smile:
(The impl of BitOr for Either was forcing the types to be the same, but there should be another type parameter that is used as BitOr<Rhs> instead of R)