These are chat archives for rust-lang/rust

29th
May 2018
Sai Zeng
@zengsai
May 29 2018 02:11

Hi, there is a Never type in future 0.3, and an implementation like this:

/// A type with no possible values.
///
/// This is used to indicate values which can never be created, such as the
/// error type of infallible futures.
///
/// This type is a stable equivalent to the `!` type from `std`.
#[derive(Debug, Copy, Clone, Eq, PartialEq, Ord, PartialOrd)]
pub enum Never {}

impl Never {
    /// Convert the `Never` type into any other type.
    pub fn never_into<T>(self) -> T {
        match self {}
    }
}

How can Never type convert to any type? what the purpose of the function? where the data of T from?

Any body known?
Kelly Thomas Kline
@kellytk
May 29 2018 02:50
I'm following the guide at https://github.com/johalun/crossrust and in the "Link in libraries so they will be built together with gcc." step make -j4 && make install fails with "/opt/cross-freebsd/x86_64-unknown-freebsd11/bin/ld: cannot find /lib/libc.so.7" and "collect2: error: ld returned 1 exit status" and I'm currently stuck. Any help would be appreciated
Michal 'vorner' Vaner
@vorner
May 29 2018 07:12
@zengsai The idea is, as Never has no possible values, nobody is able to create one and therefore this function is guaranteed not to be called. Ever. So it doesn't matter what it claims to return.
This is similar to being able to „cast“ ! into whatever ‒ ! is what panic returns.
Zakarum
@omni-viral
May 29 2018 11:33
Also ! is what break, continue and return "returns"
fn() -> usize { let _: ! = return 42; }
Dale Wijnand
@dwijnand
May 29 2018 11:56
never_into is converting from one uninhabited type (Never) to another (T) - in either case it's uninhabited so the typechecker is fine with it.
Sylwester Rąpała
@xoac
May 29 2018 11:56

Hi, is it possible to find a "source of panic". I have a somebody crate that panics with:

---- test_ttyport_set_nonstandard_baud stdout ----
        thread 'test_ttyport_set_nonstandard_baud' panicked at 'Unable to create ptty pair: Error { kind: Unknown, description: "Invalid argument" }', libcore/result.rs:945:5

I would like to find that line in code.

Andrey Lesnikov
@ozkriff
May 29 2018 11:57
RUST_BACKTRACE=1 cargo run - run it with RUST_BACKTRACE env variable, it should print a stacktrace
Sylwester Rąpała
@xoac
May 29 2018 11:59
@ozkriff this say my anything (i used full instead od 1)
Michal 'vorner' Vaner
@vorner
May 29 2018 12:00
10 is probably what you care about. It probably comes from your tests.
tests/test_tty.rs:57
Sylwester Rąpała
@xoac
May 29 2018 12:02
@ozkriff @vorner I past wrong output:
stack backtrace:
   0:    0x95ccf - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::hd7ee9e6e2fbd0546
                       at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:    0x99c27 - std::sys_common::backtrace::print::ha543f35261e05af8
                       at libstd/sys_common/backtrace.rs:71
                       at libstd/sys_common/backtrace.rs:59
   2:    0x8e2cf - std::panicking::default_hook::{{closure}}::h4e2726d8115dc6e7
                       at libstd/panicking.rs:207
   3:    0x8debf - std::panicking::default_hook::heb92eb7475fdb71c
                       at libstd/panicking.rs:217
   4:    0x8e777 - std::panicking::rust_panic_with_hook::hdc6f326636ed669e
                       at libstd/panicking.rs:402
   5:    0x8e593 - std::panicking::begin_panic_fmt::hc0834ed5723739e8
                       at libstd/panicking.rs:349
   6:    0x8e4eb - rust_begin_unwind
                       at libstd/panicking.rs:325
   7:    0xaf593 - core::panicking::panic_fmt::h16b501044b4579f2
                       at libcore/panicking.rs:72
   8:    0x11323 - core::result::unwrap_failed::he3213138cb21b6d5
                       at /checkout/src/libcore/macros.rs:26
   9:    0x10703 - <core::result::Result<T, E>>::expect::h1bb050f48e592724
                       at /checkout/src/libcore/result.rs:809
  10:    0x149bb - test_tty::test_ttyport_pair::hcb220e5ab6f69ba2
                       at tests/test_tty.rs:17
  11:    0x1673f - test_tty::__test::TESTS::{{closure}}::h7f18690bb66a3877
                       at tests/test_tty.rs:15
  12:    0x1216b - core::ops::function::FnOnce::call_once::h8364b05bf253fd24
                       at /checkout/src/libcore/ops/function.rs:223
  13:    0x416af - <F as alloc::boxed::FnBox<A>>::call_box::h72ac1ed3a3cc6cc3
                       at libtest/lib.rs:1453
                       at /checkout/src/libcore/ops/function.rs:223
                       at /checkout/src/liballoc/boxed.rs:784
  14:    0xa08cb - __rust_maybe_catch_panic
                       at libpanic_unwind/lib.rs:102
  15:    0x51d6f - std::sys_common::backtrace::__rust_begin_short_backtrace::he6595201ac341ecb
                       at /checkout/src/libstd/panicking.rs:285
                       at /checkout/src/libstd/panic.rs:361
                       at libtest/lib.rs:1408
                       at /checkout/src/libstd/sys_common/backtrace.rs:136
  16:    0x4e68f - std::panicking::try::do_call::h111ac0c765b79129
                       at /checkout/src/libstd/thread/mod.rs:406
                       at /checkout/src/libstd/panic.rs:296
                       at /checkout/src/libstd/panicking.rs:306
  17:    0xa08cb - __rust_maybe_catch_panic
                       at libpanic_unwind/lib.rs:102
  18:    0x62b17 - <F as alloc::boxed::FnBox<A>>::call_box::h609c065e073eef52
                       at /checkout/src/libstd/panicking.rs:285
                       at /checkout/src/libstd/panic.rs:361
                       at /checkout/src/libstd/thread/mod.rs:405
                       at /checkout/src/liballoc/boxed.rs:784
  19:    0x971f3 - std::sys_common::thread::start_thread::h78ffaaffe756091e
                       at /checkout/src/liballoc/boxed.rs:794
                       at libstd/sys_common/thread.rs:24
  20:    0x89ee3 - std::sys::unix::thread::Thread::new::thread_start::hfb507e299c0d513f
                       at libstd/sys/unix/thread.rs:90
I agree 10 is a place whete it ends. I am looking for begin
Maybe sth changed since last year?
Andrey Lesnikov
@ozkriff
May 29 2018 12:09

I agree 10 is a place whete it ends. I am looking for begin

hmm, it looks to me like your code begins at tests/test_tty.rs:15, then it calls at tests/test_tty.rs:17 and then it tries to unwrap some Result::Err

Maybe sth changed since last year?

Almost any path can panic theoretically. In practice, maybe things like https://github.com/rust-fuzz/afl.rs or https://github.com/rust-fuzz/cargo-fuzz may help with finding "real" panic paths?

Sylwester Rąpała
@xoac
May 29 2018 13:54
Thx for links but I can't use it
It's cross-compiled against musl
and cargo fuzz dosen't work. But can't I use gdb?
Farzeen
@thefzsalam
May 29 2018 14:37
Is PhantomData the way to achieve this? Am I making any mistakes?
trait Foo<T> {
    fn bar() -> T;
}

struct FooBar <T, F> where F: Foo<T> {
    foo: F,
    phantom: PhantomData<T> // <-- without this, rustc complains T is not used
}
Zakarum
@omni-viral
May 29 2018 14:38
where F: Foo<T> is exactly the thing you don't need on structs
Farzeen
@thefzsalam
May 29 2018 14:38
why is that?
Zakarum
@omni-viral
May 29 2018 14:39
Doing so you force user of the FooBar to always write this bound. Even if he doesn't use the knowledge that F: Foo<T> because he doesn't call Foo::bar
For example. Clone (or similar trait) implementation for FooBar
impl<T, F> Clone for FooBar<T, F>
where
  F: Foo<T> + Clone,
{
  fn clone(&self) -> Self {
    FooBar {
      foo: self.foo.clone(),
      phantom: PhantomData,
    }
  }
}
Farzeen
@thefzsalam
May 29 2018 14:41
Oh, right.
thanks @omni-viral
Zakarum
@omni-viral
May 29 2018 14:42
Also #[derive(Clone)] will add T: Clone bound too
Farzeen
@thefzsalam
May 29 2018 14:42
I just found out that this works
struct FooBar<T> {
    foo: Foo<T>
}
Zakarum
@omni-viral
May 29 2018 14:43
Now FooBar<T>: !Sized
Since Foo<T>: !Sized
You can only use it like this &FooBar { foo: foo_impl_value }
Farzeen
@thefzsalam
May 29 2018 14:45
!Sized means not Sized, right?

Actually I didn't expect that to work because,

fn foo_bar<T>(f: Foo<T>) ->T { f::bar() }

doesn't compile

So, @omni-viral, what is the right way to do this, given that the struct FooBar is only used internally in the library I am writing?
Zakarum
@omni-viral
May 29 2018 14:49
struct FooBar<F> {
    foo: F
}
And then
fn foo<F, T>(f: FooBar<F>)
where
  F: Foo<T>,
{
  F::foo()
}
Or even without f: FooBar<F> because it unused :smile:
Farzeen
@thefzsalam
May 29 2018 14:51
Cool :+1:
Zakarum
@omni-viral
May 29 2018 14:51
Follow simple rule: Add trait bound where compiler tells (would tell) you to do so.
Farzeen
@thefzsalam
May 29 2018 14:51
:D
Roger that
Zakarum
@omni-viral
May 29 2018 14:51
Start with "tells you"
And then transit to "would tell" after gathering some experience
Farzeen
@thefzsalam
May 29 2018 15:25
@omni-viral, trying to do that on impl<S,T> Foobar<S> where S: Foo<T> { ... } gives the error:
error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates.
Zakarum
@omni-viral
May 29 2018 16:12
This message was deleted
This message was deleted
You need introduce T and add bound for specific function
Zakarum
@omni-viral
May 29 2018 16:17
Not whole impl block
@thefzsalam
Zakarum
@omni-viral
May 29 2018 16:23
Compiller must be able to calculate parameters of the impl block from parameters of the type and trait. In your example T is independent from S. So this impl block is invalid
But function may introduce new parameters that are independent from parameters in impl block