[PATCH] D17778: TypedError for recoverable error handling

[Rafael Espíndola via llvm-commits]

> If we turned exceptions on we wouldn't need any API changes, but we would
> pay the overhead for exceptions and RTTI everywhere in LLVM except where we
> explicitly opt out via noexcept specifiers. To get an upper bound on this I
> did a Release (non-LTO) build of LLVM with and without exceptions+RTTI
> turned on. I didn't get past looking at the binary size differences: clang
> got >9% bigger. Other tools got between 2% and 25% bigger, with most
> clustered around a 10-15% increase. Those are some scary size regressions.

For this and for the fact that llvm is used in exception free code
bases I don't think enabling exceptions in llvm code is a viable
solution in general.

Note that in a case where someone controls both FE and backend, they
could build llvm with exceptions and have it propagate from the
backend all the way to the FE. It is just llvm always requiring
exceptions that I don't think is viable.

Given that we need at least some form of "checked std::error_code", I
am ok with this solution. I just insist that

* programs can still just use fatal errors.
* when appropriate, libraries can use lighter error handling options
like an error node in an AST.
* an effort is made to port the codebase to use this when appropriate.
In particular, pretty much anything returning a plain std::error_code
or bool+std::string is a good candidate for conversion.

Cheers,
Rafael