[PATCH] D20550: Linker: error_code'ify the IR mover. NFC.

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Tue May 24 18:49:54 PDT 2016

On 24 May 2016 at 20:34, Lang Hames <lhames at gmail.com> wrote:
> Hi Rafael,
> Just in case it's useful: You can accumulate Error instances using the
> join_errors function. It's intended for situations where you want to
> accumulate multiple diagnostics before bailing out. That said, I think it
> would be reasonable to just bail early here as you suggested.

Yes, sorry that is what I meant by "list of error" :-)

> Convertibility to error_code is important: Unless you can be certain that
> all clients of the interface have transitioned 100% to Error, you have to
> assume that a client might call errorToErrorCode, and if you haven't
> implemented the conversion that call will crash.

This is a small interface and I think we can do it. Even if we want a
fail safe, we should have a single "unhandled_category" with a single
error for the cases where every caller should be using Error.

> I've generally aimed for error_code <-> Error mappings that are reasonably
> information preserving, but we could introduce a new error_category and enum
> in the Error header: IndescribableError, and allow people who are
> introducing new Error types to map to that. It might even serve as a handy
> forcing function to get people to move over.

Yes, the IndescribableError is what I meant by the unhandled_category.
Having a rich mapping on the other hand makes me very scared of the
prospect of ever finishing the transition. In any case, we should
definitely not adding more error_categories to transition from bool to


More information about the llvm-commits mailing list