[LLVMdev] Proposal for better assertions in LLVM
viridia at gmail.com
Wed Jul 27 15:31:55 PDT 2011
On Wed, Jul 27, 2011 at 12:51 AM, Chandler Carruth <chandlerc at google.com>wrote:
> On Tue, Jul 26, 2011 at 10:41 AM, Talin <viridia at gmail.com> wrote:
>> The assertions in LLVM would be a lot more useful if they could print out
>> not only the source code of the expression that failed, but also print the
>> values of the various arguments. To that end, I have an idea for an improved
>> assert macro which would use raw_ostream. It would look something like this:
>> ASSERT_STRM(Ty == STy, "Expected " << Ty << " but got " <<
> Chromium (and several other Google open source projects) have a somewhat
> superior variant of this:
> It ends up looking like:
> CHECK(Ty == STy) << "Expected " << Ty << " .." << ...;
> The important difference is that most of the parameters go outside of the
> macro rather than inside, making error messages way more intelligible. *If*
> we want to go this direction in LLVM, I'd much rather see this formulation.
> It's still easy to have it compile away to nothing using ?: operator.
> Can you explain how it avoids evaluating the arguments in the false case? I
looked at the code but it's pretty complex.
> *If* there is a desire to go this route, I've worked closely with several
> variants of the pattern and would be happy to contribute a minimal
> However, I agree with Chris's concerns about how useful this is in LLVM.
> While I've used it on projects where it provides tremendous value, with LLVM
> I often end up in the debugger anyways. I think the automatic debugger
> trapping is marginally more useful, but only marginally. Having my debugger
> discard the SIGABRT and continue isn't too hard. On the flip side, it might
> make crash reports from users much more useful (in the absence of, or prior
> to arriving at, a reduction). I think the cost is quite low, so maybe its
> worth it, but maybe it isn't.
> I'll leave it to Chris and others to make the call, just wanted to make
> sure a slightly different implementation was on the table in case it does go
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev