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

[Lang Hames via llvm-commits]

Hi Rafael, Peter,

This is a small interface and I think we can do it.


Fair enough. I just tried to implement IndescribableError and realised is
fairly problematic in its own way, so in the interests of unblocking things
I think we should take your patch and just bail in the conversion method
for now. I'll keep thinking about IndescribableError and we can revisit it
when I've sorted out the dark corners. Sorry for the hold up!

I only had two comments on your patch:

emitError can just be: make_error<StringError>(Message.str()). There's no
need for the StringError temporary: make_error forwards arguments to
StringError's constructor the same way make_unique does.

make_error<ECError> should be errorToErrorCode: The latter is the standard
term to grep for when looking for the interface between error_code-using
API and Error-using API.

Cheers,
Lang.

On Tue, May 24, 2016 at 6:49 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> 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
> Error.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160525/0b131e81/attachment.html>