Why asserts don't provide much information?

When for example some call is wrong error message always looks like this:
Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"), function init, file /tmp/llvm-svn/llvm/lib/VMCore/Instructions.cpp, line 247.

I believe assert() statements should better be replaced with more detailed printouts of what is wrong. This will save many people a lot of debugging time.

Yuri

I concur. I've run into this exact assert at least 10 different times in the last two weeks since I started with LLVM as I'm learning the particulars of the typing system for function calls in particular.

It would be nice if it would tell you what expected signature was, what the value of i was so you know which parameter went wrong, and what the actual type passed in was, as well as what was expected. You can get this information yourself but it is a real pain.

- Curtis

I concur. I've run into this exact assert at least 10 different times in the last two weeks since I started with LLVM as I'm learning the particulars of the typing system for function calls in particular.

It would be nice if it would tell you what expected signature was, what the value of i was so you know which parameter went wrong, and what the actual type passed in was, as well as what was expected. You can get this information yourself but it is a real pain.

- Curtis

P.S. Apologies if this comes through twice. I sent from the wrong account and it went into moderation.

I've run into it as well, more times than I can count. Now asserts
are supposed to be removable, but perhaps an assert that calls a
function listing the particulars of the problem could improve things.

Hi Yuri,

Jeffrey Yasskin had a tip some time ago about this particular assertion:

"In general, when I hit one of those assertions, I gdb to it, use "p
f->dump()" to see the types of the function's arguments, and use "p
Params[i]->dump()" to see the parameter with the bad type."

HTH,
Paul

Thanks for forwarding Jeffrey's tip Paul.

Unfortunately, coming mostly from the application programming side, I haven't seriously used a command line debugger since the Apple IIe days in the early 80s (geez, i guess that makes me kinda old as far as programmers go). So I'm not familiar with gdb even at an intermediate level.

Not that gdb isn't ubiquitous for tools development or any sort of development on Linux/Unix. For application development, however, most people use an IDE. I've been doing mostly application development for the last 30 years. I'm currently using Xcode, which is both fortunately and unfortunately a gdb-based debugger, so I can use your suggestion. I'm just returning to Mac development from a long and painful journey to the hell and back that is windows MFC which stands for Most F&$*'d-Up Class Library, so I'm not yet even a seasoned Xcoder.

Still, as many of the people approaching LLVM will be considering it for embedding functionality within an application environment, I suspect that a considerable number of them will be IDE-saavy like me more than command-line tool saavy. This will be especially true of anyone coming from Windows as the Visual C++ IDE is actually an excellent product where you don't need to use the command line to do anything (Did I just complement a Microsoft product? I must be ill.)

Since this is an open-source project, I'll take a stab at improving the diagnostics messages for the gdb ignorant (or lazy like me) among us and submit the patch.

LLVM is so great in many ways, I want to do my part to help make sure that others get a favorable first impression when they try to implement a proof of concept design as part of their evaluation of the suitability of LLVM for their project.

- Curtis

Don't all IDEs have a debugger that can set a breakpoint and call
functions from the program to see what they print? If you can't set
breakpoints or call dump() on an LLVM value, you're going to have more
problems than just this assertion.

I don't think it's worth annotating all assertions with extra
information, but this one probably happens often enough to deserve it.
If anyone wants to beef it up, you can follow the example in ~Value:

#ifndef NDEBUG // Only in -g mode...
  // Check to make sure that there are no uses of this value that are still
  // around when the value is destroyed. If there are, then we have a dangling
  // reference and something is wrong. This code is here to print out what is
  // still being referenced. The value in question should be printed as
  // a <badref>
  //
  if (!use_empty()) {
    dbgs() << "While deleting: " << *VTy << " %" << getNameStr() << "\n";
    for (use_iterator I = use_begin(), E = use_end(); I != E; ++I)
      dbgs() << "Use still stuck around after Def is destroyed:"
           << **I << "\n";
  }
#endif
  assert(use_empty() && "Uses remain when a value is destroyed!");

Well yes, if you have LLVM source compiled within the IDE then it's pretty easy to set a breakpoint and the variables will be right there easy to digest. If, however, you are using LLVM as a library then this won't help you, at least not with Xcode (in my attempts anyway, its possible that I'm just doing something newbish). I can't set a breakpoint inside the library itself unless the source is compiled as part of the project. Perhaps I'm doing something wrong.

Many users of LLVM, in contrast with developers of LLVM, will not be as conversant with the internals and will also be more likely to just want to use it as a library. So I suspect they'll run into the same limitation.

- Curtis