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

[David Blaikie via llvm-commits]

On Wed, May 25, 2016 at 11:03 PM, Lang Hames via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> 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:
>

Could possibly enforce this - making MCError's ctor private & friended to
errorToErrorCode or somesuch?


> 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
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160526/06a21e92/attachment.html>