On Tue, Jul 26, 2011 at 10:59 PM, Chris Lattner <clattner at apple.com> wrote:> > On Jul 26, 2011, at 9:17 PM, Talin wrote: > > Here's an example of how this would be used: In the constructor for > ConstantVector, there's an assert: > > assert(C->getType() == T->getElementType() && > "Initializer for vector element doesn't match vector element > type!"); > > I would change this to: > > ASSERT_STRM(C->getType() == T->getElementType(), > "Initializer for vector element " << I - V.begin() << " with type " << > C->getType() << " doesn't match vector element type " << > T->getElementType()); > > With more detailed assertions like this, a much larger class of programmer > errors can be diagnosed without having to go into the debugger. > > 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 streamedarguments" 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.> -Chris >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110728/b254f536/attachment.html>
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. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110728/bf69d052/attachment.html>
On Thu, Jul 28, 2011 at 1:29 PM, Chris Lattner <clattner at apple.com> wrote:> 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. >Understood. Here's my final word on the matter: From the perspective of a user of LLVM's APIs, assertions are the primary feedback mechanism that tell me whether I am using those APIs correctly. In the time I've been using LLVM, I've made hundreds if not thousands of errors - from various causes ranging from simple typos to of misunderstanding the documentation. (As part of migrating my frontend to the new type system, I've encountered about a dozen assertion failures, most of which were quite easy to diagnose once I knew what type was involved.) Most of the time an assertion failure is the first signal that I've done something wrong. Unfortunately, "something went wrong" is about all the information I typically get from an assertion failure.> -Chris >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110728/35c37227/attachment.html>