Unreachable expression in void-1.0.2, Rust 1.16

[brson]

https://github.com/reem/rust-void.git a6e061227f47ba8798b7e828ed0ac4e25382eb15

Not on stable/beta.

128 brian@ip-10-145-43-250:~⟫ rustc +nightly -Vv
rustc 1.16.0-nightly (47c8d9fdc 2017-01-08)
binary: rustc
commit-hash: 47c8d9fdcf2e6502cf4ca7d7f059fdc1a2810afa
commit-date: 2017-01-08
host: x86_64-unknown-linux-gnu
release: 1.16.0-nightly
LLVM version: 3.9

brian@ip-10-145-43-250:~/dev/rust-void⟫ cargo +nightly test
   Compiling void v1.0.2 (file:///mnt2/dev/rust-void)
warning: unreachable pattern, #[warn(unreachable_patterns)] on by default
  --> src/lib.rs:98:13
   |
98 |             Err(e) => unreachable(e)
   |             ^^^^^^

warning: unreachable pattern, #[warn(unreachable_patterns)] on by default
   --> src/lib.rs:116:13
    |
116 |             Ok(v) => unreachable(v),
    |             ^^^^^

error: unreachable pattern
  --> src/lib.rs:98:13
   |
98 |             Err(e) => unreachable(e)
   |             ^^^^^^
   |
note: lint level defined here
  --> src/lib.rs:1:24
   |
1  | #![cfg_attr(test, deny(warnings))]
   |                        ^^^^^^^^

error: unreachable pattern
   --> src/lib.rs:116:13
    |
116 |             Ok(v) => unreachable(v),
    |             ^^^^^

error: aborting due to 2 previous errors

Build failed, waiting for other jobs to finish...
error: Could not compile `void`.

To learn more, run the command again with --verbose.

The code here is interesting. I don't quite see what the compiler does.

cc @reem

[durka]

I think this is the same as #38977?

[arielb1]

That's intentionally caused by #38069 + #[deny(unreachable_patterns)]. Can be fixed by removing the arm or allowing the lint.

[brson]

Woah!

So I can now write:

    #[inline]
    fn void_unwrap(self) -> T {
        match self {
            Ok(val) => val,
        }
    }

That is, the match is not exhaustive over its variants! That seems very very surprising to me. It is tying this reachability analysis to the semantics of match in a new way that I would not expect.

This type of match is an error on stable today.

[brson]

I guess, in some sense the new semantics only accept more code, so it's backwards compatible. As long as the lint is off you can write it with the empty pattern...

[nikomatsakis]

@brson yes, that was the idea. And yes, the example is surprising at first, but makes sense when you consider that a Void value can never exist in practice (or else you've done something wrong)

[durka]

s/wrong/unsafe :)

…

On Wed, Jan 11, 2017 at 3:03 PM, Niko Matsakis ***@***.***> wrote: @brson <https://github.com/brson> yes, that was the idea. And yes, the example is surprising at first, but makes sense when you consider that a Void value can never exist in practice (or else you've done something wrong) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#38975 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n3jeU94RMNpMtzECUdOsI3yXpvNUks5rRTWlgaJpZM4LgB57> .

[brson]

Expected behavior. Please add this as a test case.

[brson]

@eddyb says we don't need this test.