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

[Mehdi Amini via llvm-dev]

> On Feb 10, 2016, at 7:19 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
>> 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

FWIW, I support the effort Lang is leading, so it is a +1 on my side to move on! 
And I also agree with Rafael that it would be really better to limit as much as possible the mix of multiple reporting inside a component.

Lang: please CC me on the reviews, I'll be happy to follow the development.

-- 
Mehdi