orium ( Diogo Sousa )

started time in 18 days

Type system accepts wrong expression type on a statement that is unreachable

Hi everyone. There seems to be bug where an expression with type ! that is made into a "statement" by adding a ; will behave like it has type ! instead of ():

The following code typechecks correctly, even though the function body has type () and the return type is u32:

fn foo() -> u32 {
    panic!();
}

If you replace the body with panic!(); () you correctly get a type error.

Note that this is still sound, since the expression will never finish evaluation.

This happens in stable (1.46.0) as well as nightly 1.49.0-nightly (2020-10-05 a1dfd24).

created time in 19 days

issue openedrust-lang/rust

Type inference seems to pick up the wrong trait bound

Hi. I apologize if this is a dup (I tried to search, but is it not easy to distill this into words to search for). If it's not a dup please update the title to something more meaningful.

When trying to compile (in play)

pub trait Distribution<T> {}

impl Distribution<u16> for () {}

fn gen<K>() -> K
where
    (): Distribution<K> {
    todo!()
}

fn foo<T>() -> u16
where
    (): Distribution<T>,
{
    gen()
}

I get the error:

error[E0308]: mismatched types
  --> src/lib.rs:15:5
   |
11 | fn foo<T>() -> u16
   |        -       --- expected `u16` because of return type
   |        |
   |        this type parameter
...
15 |     gen()
   |     ^^^^^ expected `u16`, found type parameter `T`
   |
   = note:        expected type `u16`
           found type parameter `T`

It it should be able to determine that the hole in gen::<_>() is u16 because that's the return type of foo(). Instead the compiler thinks the hole must be T, which is not true (in fact, if you change the call to gen() to gen::<u16>() the code compiles).

This happens in stable (1.46.0) as well as nightly 1.49.0-nightly (2020-10-05 a1dfd2490a6cb456b92e).

created time in 20 days

issue commentcloudflare/wrangler

Segmentation fault after wrangler executes its command

@codenoid I think the

thread '<unnamed>' panicked at 'Client::new(): reqwest::Error { kind: Builder, source: Normal(ErrorStack([])) }', /home/ken/.cargo/registry/src/github.com-1ecc6299db9ec823/reqwest-0.10.8/src/blocking/client.rs:575:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

is caused by the same issue, so the upstream fix in rust-openssl should fix that as well.

orium

comment created time in 25 days

startedtokio-rs/tracing

started time in 25 days

startedalangibson/awesome-crdt

started time in a month

issue commentrust-lang/rust

Compiler panic with generic-typed nested closures

I was able to minify it a bit further:

fn t7p<A,B>(g: impl Fn(A) -> B) -> impl Fn(A) -> B {
    g
}

fn unify<A,B,C>(f: impl Fn(A) -> B, g: impl Fn(A) -> C) {}

fn unify2<A,B,C>(f:impl Fn(B) -> C, g: impl Fn(A) -> B) {}

fn main() {
    let f = |(_, _)| {  };
    let g = |(a, _)| { a };

    unify2(f, g);

    let t = |env| { |a| { |b| { t7p(g)(((env, a), b)) }}};

    unify(t, t7p(g));
}

bturner-bw