[llvm-dev] [RFC] Error handling in LLVM libraries.

Rafael EspĂ­ndola via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 10 19:19:16 PST 2016

> In the long-term I expect many parts of LLVM may want to migrate from
> std::error_code to TypedError, but that's ultimately a decision for the
> maintainers of the respective parts. I'll be very happy to provide input and
> support, but I don't want to pre-empt anyone else's decision on whether to
> adopt this.

That means we will forever have an incomplete transition.

We still haven't finished moving to the "new" naming style. Moving to
the current path handling took from Nov 2009 to Jun 2013.

I am still not convinced that the new system is better than a
asserting wrapper over std::error_code with diag handlers, but I don't
have the time to change Orc to use to show it. Given that I also
failed to convince you otherwise, we will probably have to go with the
view of who can actually code this.

But *please*, make an effort to use it everywhere. We still have a mix
of bool+std::string, std::error_code and ErrorOr. Are each of these
better than what you are proposing in one case or the other? Probably.
Is it worth it having unique snow flakes?  I don't think so.

In particular, please don't change just the "MachO-specific part of
X". In the past I have made an effort to keep MachO bits current when
working in MC and lib/Object. Please do the corresponding effort. For
example, if you change llvm-nm, please change all of it


More information about the llvm-dev mailing list