<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 3, 2014 at 5:08 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
How can we support AssertingVH, which behaves as a POD-like struct around a pointer in NDEBUG, and as a class with significant (important) functionality to implement asserts on dangling value handles in !NDEBUG builds?<br>

</blockquote>
<br></div>
This was in the original patch. If you have a moment I recommend that you take a look, particularly at the config.h change which is still the current 3.5 plan (the llvm_assert changes which make the bulk of the patch aren't in the plan for now though).<br>

<br>
To summarise, it's a matter of replacing the 5 or so structurally significant NDEBUG with a LLVM_DEBUG_BUILD macro definition in the generated llvm-config.h header.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
While having different components of LLVM and consumers of LLVM able to intermix NDEBUG and !NDEBUG built code freely without ABI issues is nice-to-have in my book, the functionality provided by AssertingVH is significantly more nice-to-have, and I don't see any easy ways to contain or limit the exposure of this facility to library-level consumers.<br>

</blockquote>
<br></div>
As explained above, we will retain AssertingVH exactly as is, with the structure adapting exactly as it does now to include extra bits and asserts between DEBUG and NDEBUG.<br>
<br>
The only difference is that the macro definition will be in llvm-debug.h so it'll be stable independent of external project configurations.</blockquote></div><br></div><div class="gmail_extra">If we're going to have structural differences between an asserts and a no-asserts build, why should we stress about minimizing them? That is, why not just s/NDEBUG/LLVM_NDEBUG/g (conceptually, not textually of course) and provide a per-build stable idea of whether "asserts" are on or off?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">That would seem way simpler, and would allow library users to define NDEBUG which ever way they wanted without any impact on LLVM. It would also allow us to not think about whether or not the uses of NDEBUG that are left in the headers are "safe" ODR violations (something I'm pretty suspect about to begin with in an LTO-enabled world).</div>
</div>