<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 24, 2014 at 9:41 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I fail to see why all that re-engineering effort IS "required" to support the use-cases we've provided, and why future-proofing a large body of software that
 quite honestly was never designed for it and has genuinely very few reasons why it should be.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If we're going to support bitcode as a long-term storage format, everything that pulls information out of bitcode MUST be future-proofed.  Doing it piece by
 piece is a LOT of engineering effort to make LLVM user-friendly in this way; it was never intended to have that degree of self-defense.</span></p></div></div></blockquote><div><br></div></span><div>I don't understand what you mean by "future-proofed" in this context. If you mean "never crash on bad user input", then your point doesn't make sense to me. LLVM is engineered to never crash on bad user input in the same sense that it is engineered to correctly compile code; neither is allowed, and if either happens it is a bug.</div></div></div></div></blockquote><div><br></div><div>This is true, but we can say from experience that there are a lot of these kinds of bugs and it will take a lot of effort to fix them all. Personally, I think this worth doing. We should be using the new diagnostic handler on the LLVMContext, and most of LLVM should have a way of returning without exploding.</div></div></div></div>