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:<div>

<br></div><div>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.)</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>-- <br>-- Talin<br>
</div>