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

[Lang Hames via llvm-commits]

Hi David,

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


Good call. I've added this in r270916. :)

- Lang.

On Thu, May 26, 2016 at 10:48 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> 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/34367018/attachment.html>