<p dir="auto"><code class="notranslate">iterFunc({|| ret; })</code> does not return from the outer function.</p>
<p dir="auto">Maybe we'll just have accept this, since in the absence of non-local control flow, there's no nice way to implement such returns.</p>
<p dir="auto">Sometimes when enabling debug info and optimizations at the same time, <em>rustc</em> dies with an assertion in the LLVM method <code class="notranslate">ValueHandleBase::ValueIsDeleted()</code>:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="While deleting: metadata %
An asserting value handle still pointed to this value!
UNREACHABLE executed at /home/sc/projects/rust/rust/src/llvm/lib/IR/Value.cpp:632!"><pre class="notranslate"><code class="notranslate">While deleting: metadata %
An asserting value handle still pointed to this value!
UNREACHABLE executed at /home/sc/projects/rust/rust/src/llvm/lib/IR/Value.cpp:632!
</code></pre></div>
<p dir="auto">This is one the major issues keeping debug info from being end-user ready (see <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="20689392" data-permission-text="Title is private" data-url="https://github.com/rust-lang/rust/issues/9770" data-hovercard-type="issue" data-hovercard-url="/rust-lang/rust/issues/9770/hovercard" href="https://github.com/rust-lang/rust/issues/9770">#9770</a>).</p>
<p dir="auto">I was already able to identify the cause for the assertion:<br>
The failure itself says that a value handle still points to the metadata node that is currently being deleted. This leaked handle is created in LLVM's <code class="notranslate">DwarfDebug::collectDeadVariables()</code> on a path that is only hit with optimizations activated. That's why the assertion is never triggered when compiling something without the <code class="notranslate">-O</code> flag.</p>
<p dir="auto">The memory leak occurs because the method cannot handle duplicate entries in the list of subprograms in the compile unit. This is a bug in LLVM: <a href="http://llvm.org/bugs/show_bug.cgi?id=16017" rel="nofollow">http://llvm.org/bugs/show_bug.cgi?id=16017</a><br>
It's not clear yet how it will be fixed exactly.</p>
<p dir="auto">But the issue should also be tackled on our side: That LLVM reacts with a memory leak to invalid input is unfortunate but it's still us that generate the invalid input. The main issue here is that some functions are translated more than once (see issue <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="15933204" data-permission-text="Title is private" data-url="https://github.com/rust-lang/rust/issues/7349" data-hovercard-type="issue" data-hovercard-url="/rust-lang/rust/issues/7349/hovercard" href="https://github.com/rust-lang/rust/issues/7349">#7349</a>) and thus they are also added to the debug info function list more than once.</p>
<p dir="auto">I think the best way to fix this issue is to fix <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="15933204" data-permission-text="Title is private" data-url="https://github.com/rust-lang/rust/issues/7349" data-hovercard-type="issue" data-hovercard-url="/rust-lang/rust/issues/7349/hovercard" href="https://github.com/rust-lang/rust/issues/7349">#7349</a>. This way we don't have to wait for LLVM to take care of their side. Also, the folks at LLVM might decide to just assert on invalid input, so we have take care of this anyway.</p>