These are chat archives for rust-lang/rust

1st
Dec 2017
Michal 'vorner' Vaner
@vorner
Dec 01 2017 06:17
@nyarly You mean it attracts more people as it gains developers, or that it somehow makes „physical sense“, like your structs don't magically multiply by themselves just like the pots in the cupboard don't magically multiply?
Fra ns
@snarf95_twitter
Dec 01 2017 11:01
Is there any difference in performance when using arrayvec vs smallvec that hasn’t “spilled”
Denis Lisov
@tanriol
Dec 01 2017 11:02
@snarf95_twitter Benchmark it!
Fra ns
@snarf95_twitter
Dec 01 2017 11:05
Good point ;p
Or maybe I should try to read the code to get a better idea of the beast
Denis Lisov
@tanriol
Dec 01 2017 11:07
Note that for an optimizing compiler it's often not quite obvious what works faster :-)
Fra ns
@snarf95_twitter
Dec 01 2017 11:12
Yeah another good point my guts/intuition tells me that arrayvec will be faster but can’t know for sure
Zakarum
@omni-viral
Dec 01 2017 12:05
In theory arrayvec should be faster as it shouldn't check if data is on stack or on heap
But in some cases compiler can be sure that data will be on stack in smallvec
Denis Lisov
@tanriol
Dec 01 2017 12:06
...in practice, it may not matter on modern CPUs, being a single easily predicted branch.
Zakarum
@omni-viral
Dec 01 2017 12:07
^
Denis Lisov
@tanriol
Dec 01 2017 12:08
So the only true answer is to benchmark. Ideally, benchmark your code in real-life situations and not a simplified example.
Sander Maijers
@sanmai-NL
Dec 01 2017 12:44
Does anyone know how to override crate level attributes on items? This does not work for me:
#![cfg_attr(feature = "cargo-clippy", deny(clippy_pedantic))]

#[cfg_attr(feature = "cargo-clippy", allow(use_debug))]
Zakarum
@omni-viral
Dec 01 2017 12:46
#[cfg_attr(feature = "cargo-clippy", allow(use_debug))]
mod foo;
Should work
Or
// in file foo.rs
#![cfg_attr(feature = "cargo-clippy", allow(use_debug))]
Sander Maijers
@sanmai-NL
Dec 01 2017 12:48
@omni-viral: Thanks, but I wish to allow not on a whole crate or module, but on a statement.
Zakarum
@omni-viral
Dec 01 2017 12:48
#[cfg_attr(feature = "cargo-clippy", allow(use_debug))]
fn foo() -> { ... }
Should work too
But not on the single statement
AFAIK
Sander Maijers
@sanmai-NL
Dec 01 2017 12:49
That is strange, since it works on single statements for non-Clippy attributes as far as I remember
so for rustc lints
Zakarum
@omni-viral
Dec 01 2017 12:49
Maybe it should work on single statments. IDK :smile:
Never tried
Sander Maijers
@sanmai-NL
Dec 01 2017 12:50
Does not work for me at least
Zakarum
@omni-viral
Dec 01 2017 12:50
It doesn't compile or attribute doesn't affect your statement?
blankhart
@blankhart
Dec 01 2017 13:26
hi, new to rust. i have a lib.rs that declares pub mod bit_sieve; and pub mod example; code inside example can access the struct BitSieve by referring to bit_sieve::BitSieve but if i say use bit_sieve::BitSieve;the compiler is baffled by an unresolved import. this seems highly unintuitive behavior. any help?
Steve Klabnik
@steveklabnik
Dec 01 2017 13:27
hm
so
i'm trying to reproduce here
"code inside example can acccess bitsieve by referring to" <- this part seems wrong to me?
like, i get an error there
which is what i'd expect
Zakarum
@omni-viral
Dec 01 2017 13:32
You should be able to refer it as ::bit_sieve::BitSieve
Steve Klabnik
@steveklabnik
Dec 01 2017 13:32
can you show me how your code is different than this?
blankhart
@blankhart
Dec 01 2017 13:33
oh i see what happened. sorry will come back if i have an issue.
Steve Klabnik
@steveklabnik
Dec 01 2017 13:33
cool :)
Zakarum
@omni-viral
Dec 01 2017 13:33
So what was causing the problem?
blankhart
@blankhart
Dec 01 2017 13:37
test code not being compiled. i thought it was compiling
i am still having trouble resolving the import though - lib.rs has bit_sieve and example both as top-level modules with files declared in the same directory. from example, shouldn't it be use super::bit_sieve::BitSieve?
use ::bit_sieve::BitSieve doesn't work either
Steve Klabnik
@steveklabnik
Dec 01 2017 13:39
i personally prefer to not use super and always go from the root unless i'm very deeply nested
use :: is redundant, as use starts from the root by default
blankhart
@blankhart
Dec 01 2017 13:48
thanks all. i see it working in the playground and can make it work in a minimal cargo new. it is still not working in my project and i can't figure out why.
but if i can't reproduce it in an easy sandbox i can't imagine anyone here can help!
Steve Klabnik
@steveklabnik
Dec 01 2017 13:49
maybe, paste the exact error?
blankhart
@blankhart
Dec 01 2017 13:54

``error[E0432]: unresolved importbit_sieve--> src/example.rs:1:5 | 1 | use bit_sieve::BitSieve; | ^^^^^^^^^ Maybe a missingextern crate bit_sieve;`?

error: aborting due to previous error
```

oh i think i figured it out
blankhart
@blankhart
Dec 01 2017 14:01
this still had to do with inconsistent use of test directives. there was one in the lib.rs file that i didn't realize it was picking up.
Steve Klabnik
@steveklabnik
Dec 01 2017 14:01
so for this to work, you'd need 'mod bit_sieve;' in your lib.rs, and struct BitSeieve in src/bit_sieve.rs or src/bit_sieve/mod.rs
ah ha
blankhart
@blankhart
Dec 01 2017 14:02
yeah that's what i had
i need to get a better grasp of the different test directives. it wasn't immediately obvious from the compiler error what was the cause but it makes sense now. thanks for the responses and sorry for the distraction
Steve Klabnik
@steveklabnik
Dec 01 2017 14:03
it's all good, we're here to help
Judson Lester
@nyarly
Dec 01 2017 18:21
@wdecoster I can sympathize. Whereabouts are you?
@vorner Rust has gravity in two senses: references go easily "down" the callchain, but it's hard to get them back up, and in terms of access control: you can always reach down the module namespace to the root, (or it's antigravity, because you reach up to the root...) but modules have to be pub to reach down.
Wouter De Coster
@wdecoster
Dec 01 2017 23:05
@nyarly from Belgium. Doing my PhD in a center where most colleagues don't code and use excel ;)