[LLVMdev] Two suggestions for improving LLVM error reporting

[Talin]

I realize that LLVM assertion results aren't intended to be seen by
end-users ever - they are there to tell front-end developers that they
screwed up. Even so, I can think of two things that would make it easier for
front-end developers to track down what they did wrong without having to
jump into the debugger:

1) Be able to set a "default module" for dump(). The version of dump() in
llvm::Type takes a module parameter, which allows the type to be printed out
using the type names registered in that module. However, the various asserts
which call dump() or str() don't have a module pointer handy, which causes
the type to be printed out as unrecognizable gobbledygook. If there was some
way that we could associate either a default module with the LLVMContext -
or perhaps register type names with the LLVMContext directly - and have
dump() with no arguments use these name mappings - it would make the output
more readable. (I kind of like the idea of having a type name dictionary in
the LLVM context which is used whenever there is no module pointer handy.
For one thing, I could fill it with more readable names than the ones I use
in the module's name table.)

2) In the case where type names are available, never print out type names in
the form of "%26". I realize that not all types have names - but at least
always expand one level, so we can tell whether it's a struct or a pointer
or whatever. "{ %32 }" or "%32*" tells me a lot more than just a number by
itself. Got a CreateLoad() call that failed? Well if it prints out "{ %32 }"
for the assertion argument you instantly know why, even if you don't know
what "%32" resolves to.

In fact, what would be even cooler would be to set a threshold for the
number of levels that were always expanded. I hate trying to read
400-character-long type names, but expanding two or three levels would be
quite useful.

-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100107/2927f7e6/attachment.html>