<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 12, 2013 at 1:20 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.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">n Nov 11, 2013, at 12:09 PM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:<br>

<br>
>> Even when you have a !<span class="il">NDEBUG</span> build, the platform assert() is pretty<br>
>> crummy on Windows and generates, at best a UTF-16 dump, or sometimes<br>
>> just pops up a dialog. WebKit and other projects take the same approach<br>
>> and define their own assertion macros to deal with this portably.<br>
>><br>
>> So as far as I can tell, as long as the headers use assert(), they need<br>
>> to use our own version in order for the definition to match.<br>
><br>
> Chris,<br>
><br>
> Having said that, I agree it's worth trying without llvm_assert() to see<br>
> how far it gets.<br>
><br>
> I'll pull together a rework of this patchset with just the build system<br>
> and structure changes alone to see how far it gets.<br>
><br>
> The key thing then is to make sure that it's safe to enable the<br>
> assertions in the headers if an application is built with !<span class="il">NDEBUG</span> and<br>
> linked against an <span class="il">NDEBUG</span> version of LLVM.<br>
<br>
</div>Sounds great.  I'm pretty confident that there will be no problems - in practice - from any ODR violations that might arise from "assert" differing across library boundaries.  We would want some pretty strong practical justification for breaking away from standard assert.</blockquote>
</div><br>Sorry to dig up this thread, but when re-reading it, I was surprised that everyone seems to think this will be easily done across all of LLVM.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">We also have quite a few places in LLVM today that conserve memory usage in non-assert builds by removing unnecessary members of classes. We can say that this makes the ABI more fragile, but it is a valuable space optimization. Chris, are you saying to strongly believe that these should only be allowed for classes that are not visible in the C++ API? I find that surprising, as LLVM has historically prioritized efficiency and developer tools over ABI stability in our C++ APIs. Build-level instability is certainly a different beast from version stability, but I wanted to make sure the ramifications of this shift were being considered by everyone. (They hadn't by me.)</div>
</div>