[LLVMdev] Proposal for better assertions in LLVM

Chris Lattner clattner at apple.com
Thu Jul 28 13:29:03 PDT 2011

On Jul 28, 2011, at 12:07 PM, Talin wrote:
>> Because the stream is a raw_ostream, LLVM types and values can easily be printed to the stream without having to convert them to string form.
> I'm unconvinced that this is worth it at all.  This is only going to allow you to "avoid going into the debugger" in the most trivial cases.
> Question - are you opposed to having a general "assertion with streamed arguments" facility in llvm/Support at all, or are you merely opposed to the work involved in replacing the existing assertions en-masse? If it's the latter, I'll make you a deal - every time I get an assert that I don't think gives me enough information, I'll send a patch to improve it. But that can only happen if the general mechanism is in place first. And I'd use that general mechanism in my own code regardless of whether it's used in LLVM or not.

First, I don't see a problem here.  "assert" is a standard C feature, and I consider it to be good enough.  "Good enough" is defined as being a debugging aid for trapping and enforcing preconditions that can be disabled in a production build of the code.

I don't like the suggestions proposed for a few reasons:

1. Introducing weird macros for assertion checking is another barrier to learning the code, therefore they should either be really obvious or provide significant-enough value to make them worth the barrier.

2. I don't see the goal of assertions to make it so you don't have to debug problems in a debugger.  If that's the value of any change here, then I don't see it being worth the cost.

3. I don't want to bloat production builds with raw ostream stuff.  This can be solved depending on how the macro is designed, I'm just sayin'. :)

Custom assertion macros are nothing new, there is a reason LLVM hasn't used them until now.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110728/bf69d052/attachment.html>

More information about the llvm-dev mailing list