[llvm-dev] MemoryBuffer: Migrating to Expected/llvm::Error from ErrorOr/std::error_code

[Jordan Rupprecht via llvm-dev]

Sounds like a good way to incrementally do a mass migration without
disrupting downstream users so much, so LGTM.

On Sun, Sep 26, 2021 at 12:48 PM Lang Hames <lhames at gmail.com> wrote:

> I like this idea. MemoryBuffer is one of the biggest remaining users of
> ErrorOr (along with sys::FileSystem and VirtualFileSystem). Migrating
> MemoryBuffer to Expected would get us that much closer to eliminating
> ErrorOr entirely, which seems worth some churn.
>
> -- Lang.
>
> On Sun, Sep 19, 2021 at 2:44 PM David Blaikie <dblaikie at gmail.com> wrote:
>
>> Hey folks - I'm/we're considering a somewhat laborious/disruptive
>> refactoring for MemoryBuffer's APIs to improve error handling safety.
>> Details here:  https://reviews.llvm.org/D109345
>>
>> Duncan's pointed out that a reasonable migration strategy would be to:
>>
>>    1. Add MemoryBufferErrorAPI (wrapping APIs with errorOrToExpected)
>>    and MemoryBufferErrorCodeAPI (alias for MemoryBuffer) in the same commit.
>>    2. Migrate in-tree callers to MemoryBufferErrorCodeAPI (via mass
>>    rename). (Could even move some to MemoryBufferErrorAPI?)
>>    3. Update MemoryBuffer to use Error/Expected APIs, change
>>    MemoryBufferErrorAPI to an alias of it, and leave behind
>>    MemoryBufferErrorCodeAPI (wrapping APIs with expectedToErrorOr).
>>    4. One or more commits:
>>       1. Migrate in-tree callers to MemoryBuffer.
>>       2. Delete MemoryBufferErrorAPI alias.
>>    5. Delete MemoryBufferErrorCodeAPI wrappers.
>>
>> (this isn't the only option (some variations discussed on the code
>> review) - but something along these lines that separates the semantic
>> changes from the renaming and makes it easier for folks with stable release
>> branches to still cherry pick pieces of this without other pieces (eg: they
>> can pick any amount of 1-4 without 5, specifically they could take 1-2, do
>> a mass-rename on their branch of "MemoryBuffer:: ->
>> MemoryBufferErrorCodeAPI::" and then be pretty stable/relatively easy to
>> cherry pick things after that)
>>
>> What do folks think of this? Any major objections (including "the churn
>> doesn't seem worth the benefit" - happy to discuss that further), nuanced
>> situations/tweaks/particular scenarios that we should make an effort to
>> account for?
>>
>> If there aren't huge objections - I'll probably start this in the next
>> O(weeks).
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210930/d8a5e693/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4002 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210930/d8a5e693/attachment.bin>