Change:
}; for scope in self.scopes.iter_mut().rev() { <del> if scope.extent == extent { </del> <ins> let this_scope = scope.extent == extent; // When building drops, we try to cache chains of drops in such a way so these drops // could be reused by the drops which would branch into the cached (already built) // blocks.  This, however, means that whenever we add a drop into a scope which already // had some blocks built (and thus, cached) for it, we must invalidate all caches which // might branch into the scope which had a drop just added to it. This is necessary, // because otherwise some other code might use the cache to branch into already built // chain of drops, essentially ignoring the newly added drop. // // For example consider there’s two scopes with a drop in each. These are built and // thus the caches are filled: // // +--------------------------------------------------------+ // | +---------------------------------+                    | // | | +--------+     +-------------+  |  +---------------+ | // | | | return | <-+ | drop(outer) | <-+ |  drop(middle) | | // | | +--------+     +-------------+  |  +---------------+ | // | +------------|outer_scope cache|--+                    | // +------------------------------|middle_scope cache|------+ // // Now, a new, inner-most scope is added along with a new drop into both inner-most and // outer-most scopes: // // +------------------------------------------------------------+ // | +----------------------------------+                       | // | | +--------+      +-------------+  |   +---------------+   | +-------------+ // | | | return | <+   | drop(new)   | <-+  |  drop(middle) | <--+| drop(inner) | // | | +--------+  |   | drop(outer) |  |   +---------------+   | +-------------+ // | |             +-+ +-------------+  |                       | // | +---|invalid outer_scope cache|----+                       | // +----=----------------|invalid middle_scope cache|-----------+ // // If, when adding `drop(new)` we do not invalidate the cached blocks for both // outer_scope and middle_scope, then, when building drops for the inner (right-most) // scope, the old, cached blocks, without `drop(new)` will get used, producing the // wrong results. // // The cache and its invalidation for unwind branch is somewhat special. The cache is // per-drop, rather than per scope, which has a several different implications. Adding // a new drop into a scope will not invalidate cached blocks of the prior drops in the // scope. That is true, because none of the already existing drops will have an edge // into a block with the newly added drop. // // Note that this code iterates scopes from the inner-most to the outer-most, // invalidating caches of each scope visited. This way bare minimum of the // caches gets invalidated. i.e. if a new drop is added into the middle scope, the // cache of outer scpoe stays intact. let invalidate_unwind = needs_drop && !this_scope; scope.invalidate_cache(invalidate_unwind); if this_scope { </ins> if let DropKind::Value { .. } = drop_kind { scope.needs_cleanup = true; } <del> // No need to invalidate any caches here. The just-scheduled drop will branch into // the drop that comes before it in the vector. </del> scope.drops.push(DropData { span: span, location: lvalue.clone(), kind: drop_kind }); return; <del> } else { // We must invalidate all the cached_blocks leading up to the scope we’re // looking for, because all of the blocks in the chain will become incorrect. if let DropKind::Value { .. } = drop_kind { scope.invalidate_cache() } </del> } } span_bug!(span, "extent {:?} not in scope to drop {:?}", extent, lvalue);

Discussion:
This was discovered in database connection pooling where connections were not returned to the pool properly, and reported under Unfortunately I do not have example code small enough to share at this point. I narrowed down the rust-nightly version that introduced the bug to nightly-2016-08-03-x86_64-unknown-linux-gnu
when compiled with RUSTFLAGS="-Zorbit=off" the issue does not appear, so yes it is the MIR as suspected.
The compiler not running drop glue is not considered unsafe behaviour (i.e. it is allowed to happen), but it is still weird this happens. cc could be your drop elaboration not catching this () case? Something that we could run without having postgresql installed would be ideal test case, even if it depended on other crates for now.
Minimal reproduction:
More minimal: Removing either of early s in the function makes the issue go away. Seems like a scoping issue.
regression-from-stable-to-nightly (for a two more days at least).
Yeah I jumped the gun on the tag, but the beta is building right now.
I saw your commit -- I feel like the extent should be unique for the cleanup scope. That is, we should push a given extent only once -- but perhaps I am wrong about this? It'd be good to add an assertion (or warning) for when we push cleanup scopes with the same extent more than once so we can see what it happens.
Ah, but reading IRC chatter I see that the problem is that the extent of the "outermost scope" changed and thus the helper is out of date? That seems pretty plausible.
As pointed out on the IRC the commit linked above is a shot in the dark and is not a fix.