[PATCH] D20550: Linker: error_code'ify the IR mover. NFC.
Lang Hames via llvm-commits
llvm-commits at lists.llvm.org
Thu May 26 14:22:32 PDT 2016
Could possibly enforce this - making MCError's ctor private & friended to
> errorToErrorCode or somesuch?
Good call. I've added this in r270916. :)
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.
>> 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
>>> > 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
>>> > all clients of the interface have transitioned 100% to Error, you have
>>> > 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
>>> > 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
>>> > 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
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits