<div dir="ltr">Hi Rafael,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">For this and for the fact that llvm is used in exception free code<br></span><span style="font-size:13px">bases I don't think enabling exceptions in llvm code is a viable<br></span><span style="font-size:13px">solution in general.</span></blockquote><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Agreed.</span></div><div><span style="font-size:13px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px"> I just insist that</span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br style="font-size:13px"><span style="font-size:13px">* programs can still just use fatal errors.</span></blockquote><div><span style="font-size:13px"><br></span></div><div>Yep. One extra thing that I would like to codify (but haven't added to the docs in this patch) is that the fatal error mechanism for programs should call exit, rather than crashing or calling abort. We want program termination due to recoverable errors to look like ordinary program termination with an error code, rather than a crash.</div><div><span style="font-size:13px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">* when appropriate, libraries can use lighter error handling options<br></span><span style="font-size:13px">like an error node in an AST.</span></blockquote><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Sure.</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">* an effort is made to port the codebase to use this when appropriate.<br></span><span style="font-size:13px">In particular, pretty much anything returning a plain std::error_code<br></span><span style="font-size:13px">or bool+std::string is a good candidate for conversion.</span></blockquote><div><span style="font-size:13px"><br></span></div><div>Sounds good to me. Uses of std::error_code will be easy enough to find. Boolean returns will be a little more difficult, but we might even be able to write a clang tool to spot them.</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><span style="font-size:13px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 3, 2016 at 4:03 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> If we turned exceptions on we wouldn't need any API changes, but we would<br>
> pay the overhead for exceptions and RTTI everywhere in LLVM except where we<br>
> explicitly opt out via noexcept specifiers. To get an upper bound on this I<br>
> did a Release (non-LTO) build of LLVM with and without exceptions+RTTI<br>
> turned on. I didn't get past looking at the binary size differences: clang<br>
> got >9% bigger. Other tools got between 2% and 25% bigger, with most<br>
> clustered around a 10-15% increase. Those are some scary size regressions.<br>
<br>
</span>For this and for the fact that llvm is used in exception free code<br>
bases I don't think enabling exceptions in llvm code is a viable<br>
solution in general.<br>
<br>
Note that in a case where someone controls both FE and backend, they<br>
could build llvm with exceptions and have it propagate from the<br>
backend all the way to the FE. It is just llvm always requiring<br>
exceptions that I don't think is viable.<br>
<br>
Given that we need at least some form of "checked std::error_code", I<br>
am ok with this solution. I just insist that<br>
<br>
* programs can still just use fatal errors.<br>
* when appropriate, libraries can use lighter error handling options<br>
like an error node in an AST.<br>
* an effort is made to port the codebase to use this when appropriate.<br>
In particular, pretty much anything returning a plain std::error_code<br>
or bool+std::string is a good candidate for conversion.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>