<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 19, 2016 at 2:20 PM Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
<br class="gmail_msg">
I’m surprise by your aversion to assertions, what is your suggested alternative? Are you expecting to check and handle every possible invariants everywhere and recover (or signal an error) properly? That does not seem practical, and it seems to me that it'd lead to just involving UB (or breaking design invariant) without actually noticing it.<br class="gmail_msg">
<br class="gmail_msg">
> Also many asserts are in header files so even if you build llvm and clang with asserts off, but then build our project that uses LLVM with asserts on, you get LLVM and clang asserts when you don't want them.<br class="gmail_msg">
<br class="gmail_msg">
It is not really supported to use the LLVM C++ headers without assertions and link to a LLVM build with assertions (and vice-versa).<br class="gmail_msg"></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It seems to me that you are mixing two things: asserting on user inputs vs asserting on internal invariants of the system. LLVM is very intensive about asserting on the second category and this seems fine to me.<br class="gmail_msg">
Asserting on external inputs is not great (in LLVM as much as in LLDB).<br class="gmail_msg">
<br class="gmail_msg">
The asserting error class above falls into the second category and is a great tool to enforce programmer error<br class="gmail_msg"><br class="gmail_msg"></blockquote><div><br></div><div>I can kind of see both sides on this one.  Yes, if you can catch instances of UB before it happens that's helpful.  At the same time, when you've got a product (such as, say, Xcode), you also want to try as hard as possible not to bring the whole product down.  In lldb we have lldbassert, which asserts for real in debug, but in release it logs an error to a file.  This is nice because if someone submits a crash report, we can see the assertion failure in the log file.</div><div><br></div><div>Now, obviously the *real* solution is to make LLDB out-of-process so it doesn't bring down Xcode when it crashes.  But (and I have no knowledge of the Xcode / LLDB integration) I can easily see this being a monumental amount of effort.</div><div><br></div><div>Personally, asserting in LLDB doesn't affect me and I'm fine with lldb::Error asserting..  But I can kind of see the argument for not wanting it to assert.  </div><div><br></div><div>On the other hand, if we had better test coverage, then all of these assertions would be caught during test anyway.  Which brings us back to item #2 on my list...</div></div></div>