Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::ops::Deref; fn main() { if env_var("FOOBAR").as_ref().map(Deref::deref).ok() == Some("yes") { panic!() } let env_home: Result<String, ()> = Ok("foo-bar-baz".to_string()); let env_home = env_home.as_ref().map(Deref::deref).ok(); if env_home == Some("") { panic!() } } #[inline(never)] fn env_var(s: &str) -> Result<String, VarError> { Err(VarError::NotPresent) } pub enum VarError { NotPresent, NotUnicode(String), } </ins>

Discussion:
rustup reports of 0.6.1 crashes: These were built with rustup 0.6.0 crashed on OS X 10.10+. Fixed with a strategic That was built with Reducing these has been very difficult and I have nothing for them right now. cc
Do you know of a nightly which doesn't result in crashes?
looking for one now.
rust- looks like the exact same issue AFAICT.
from 2016-08-18 is the first nightly that miscompiles. Curiously this is also the first 1.13 nightly. Unfortunately the bug is on beta too. reproducing: commit nightly results: 2016-08-10, rustc 1.12.0-nightly ( 2016-08-09) - good 2016-08-16, rustc 1.12.0-nightly ( 2016-08-15) - build error 2016-08-17, rustc 1.12.0-nightly ( 2016-08-16) - build error 2016-08-18, rustc 1.13.0-nightly ( 2016-08-17) - bad 2016-08-22, rustc 1.13.0-nightly ( 2016-08-21) - bad 2016-08-26, rustc 1.13.0-nightly ( 2016-08-25) - bad stable/beta results: rustc 1.11.0 ( 2016-08-15) - good rustc 1.12.0-beta.2 ( 2016-08-24) - bad! beta-2016-08-16, rustc 1.12.0-beta.1 ( 2016-08-16) - buld error
Removing the from appears to make the crash go away.
I am trying to minimize a test case next.
Reduced case. This segfaults on x86_64-unknown-linux-gnu with , compiled with .
Normalized to: Backtrace is: Note the passed to .
So far I've found that the drop glue for optimizes to start with: That is reading the data pointer of the (which may be null in the case, where it represents ) and assuming it's .

While the null check which distinguishes between and is still there, it gets optimized out later, due to that metadata on the first . EDIT: Those 3 instructions are for the case, however, the IR ends up looking like: The has turned into a (presumably "everything but "). Which is still fine, is taken for and for , so you would think_ it'd work. But SimplifyCFG comes in and shoves the load into the entry block: What does this mean? LLVM has a nasty (class of) bug around metadata hints, not updating/removing them when needed MIR trans and the lifetime intrinsics are coincidental factors, causing the crash, not the misoptimization the assembly is pretty similar without lifetime intrinsics, the null check is still missing
Barebones reproduction:
Found a LLVM commit should've fixed this (but apparently didn't fully?): EDIT: Most likely  also needs that metadata-stripping treatment.
Filed LLVM bug report:
But I thought that bad-metadata loads only result in , not in UB. That's how the last of these bugs were fixed.
Just is useless, the metadata is there to kill later redundant checks. Hopefully the fix is just to add one or two of those metadata stripping loops to that unhandled case.
Fix is Recommend backport to beta, too.
Thanks a bunch
LLVM patch was merged to 3.9 stable branch in and will be included in 3.9.1 release.