This is an archive of the discontinued LLVM Phabricator instance.

[llvm-objcopy][NFC] refactor error handling. part 1.
ClosedPublic

Authored by avl on Sep 22 2020, 1:19 PM.

Details

Summary

Remove usages of special error reporting functions(error(),
reportError()). This patch is extracted from D87987.
Errors are reported as Expected<>/Error returning values.
This part is for MachO subfolder of llvm-objcopy.

Testing: check-all.

Diff Detail

Event Timeline

avl created this revision.Sep 22 2020, 1:19 PM
Herald added a project: Restricted Project. · View Herald Transcript
avl requested review of this revision.Sep 22 2020, 1:19 PM
jhenderson added inline comments.Sep 23 2020, 1:21 AM
llvm/tools/llvm-objcopy/CopyConfig.h
239–242 ↗(On Diff #293556)

Why did this code change? It looks semantically identical, and I think it's actually a little less readable.

llvm/tools/llvm-objcopy/MachO/MachOObjcopy.cpp
381

Cleaner code would be to just do:

Expected<std::unique_ptr<Object>> O = Reader.create();
if (!ObjOrErr)
  return O.takeError();
...
383–386

If I'm following things correctly, this piece of code is dead? Even if there were errors in the create method, they should now be reported via the Expected being returned. If it is dead, please remove it. If not, I think we should change the behaviour to report the error in the same manner as the other errors.

llvm/tools/llvm-objcopy/llvm-objcopy.h
27–42 ↗(On Diff #293556)

If I'm not mistaken, this whole function can just be replaced with a single createStringError() call, similar to what we often do in llvm-readobj (see e.g. https://github.com/llvm/llvm-project/blob/master/llvm/tools/llvm-readobj/ELFDumper.cpp#L5348).

avl added inline comments.Sep 23 2020, 2:33 AM
llvm/tools/llvm-objcopy/CopyConfig.h
239–242 ↗(On Diff #293556)

I personally found this way more readable. I used it elsewhere and changed in this place so that it looks equal to other places. Will change back.

llvm/tools/llvm-objcopy/MachO/MachOObjcopy.cpp
381

Ok, will use that pattern.

383–386

yes, it looks dead. I left it just in case. Will remove.

llvm/tools/llvm-objcopy/llvm-objcopy.h
27–42 ↗(On Diff #293556)

OK.

avl updated this revision to Diff 293694.Sep 23 2020, 4:26 AM

addressed comments.

jhenderson added inline comments.Sep 23 2020, 5:52 AM
llvm/tools/llvm-objcopy/MachO/MachOObjcopy.cpp
370

I think you don't need the asser. A lot of our code base don't bother asserting that something is not null, because it's not really any different from a crash in that situation.

llvm/tools/llvm-objcopy/MachO/MachOReader.cpp
89

Can you use the error code associated with SecRef instead of errc::invalid_argument here?

135–141

Here and below in these case statements, due to the scoping issue, I'm okay if you want to go with your previous version.

avl added inline comments.Sep 23 2020, 7:07 AM
llvm/tools/llvm-objcopy/MachO/MachOReader.cpp
89

As far as I understand that could be done in that way:

inline Error errorWithContext(StringRef Context, Error E) {
  assert(E);
  std::string Buf;
  raw_string_ostream OS(Buf);
  Optional<std::error_code> EC;
  handleAllErrors(std::move(E), [&](const ErrorInfoBase &EI) {
    OS << "'" + Context + "': ";
    if (!EC)
      EC = EI.convertToErrorCode();
    EI.log(OS);
    OS << "\n";
  });
  OS.flush();

  return createStringError(*EC, Buf);
}

but you`ve asked me to not create a special routine for that.

jhenderson added inline comments.Sep 23 2020, 7:42 AM
llvm/tools/llvm-objcopy/MachO/MachOReader.cpp
89

I misremembered how the interface worked. There's an errorToErrorCode() function, but that consumes the input Error, which we don't want. Leave it as-is.

avl updated this revision to Diff 293742.Sep 23 2020, 8:12 AM

addressed comments.

jhenderson accepted this revision.Sep 23 2020, 11:53 PM

Looks good from my point of view. Might be worth a second opinion (@grimar/@MaskRay/@rupprecht/@alexshap?)

This revision is now accepted and ready to land.Sep 23 2020, 11:53 PM

apart from the minor comments, I think this change is in the right direction.

llvm/tools/llvm-objcopy/MachO/MachOObjcopy.cpp
367

nit: perhaps, I'd keep the old name of the variable (simply O) because ObjOrErr somehow appears to suggest that the type of this variable is ErrorOr<...> (https://llvm.org/doxygen/classllvm_1_1ErrorOr.html ) which is not the case.

llvm/tools/llvm-objcopy/MachO/MachOReader.cpp
89

I'm wondering - why not simply bubble up the error ?

127–132

the same as above - the name SectionsOrErr appears to be slightly misleading, I'd probably just call it Sections.

avl added inline comments.Sep 24 2020, 1:04 AM
llvm/tools/llvm-objcopy/MachO/MachOReader.cpp
89

My guess is that original intention is to add file name MachOObj.getFileName to have better reporting. If we would like to add filename then we could not bubble up original error.

avl updated this revision to Diff 293966.Sep 24 2020, 1:10 AM

renamed variables.

llvm/tools/llvm-objcopy/MachO/MachOReader.cpp
89

On the line 359 (in MachOObjcopy.cpp) we can use createFileError (similarly to how we deal with handleArgs) and this would probably enable us to get rid of these conversions / the code would simplify a bit.
P.S. since we were not propagating errors before this change we had to adjust the message in multiple places
what would you say to this ?

llvm/tools/llvm-objcopy/MachO/MachOReader.cpp
91–97

DataOrErr -> Data or Content

avl marked an inline comment as done.Sep 24 2020, 1:54 AM
avl added inline comments.
llvm/tools/llvm-objcopy/MachO/MachOReader.cpp
89

Ah, you mean to use createFileError instead of createString Error. Right, that would be better usage.

As to adjusting the message in multiple places - did you mean checking other usages of createStringError and replace them with createFileError if applicable ? It looks like all other usages of createStringError inside MachO subfolder are not suitable to replacing with createFileError.

avl updated this revision to Diff 293975.Sep 24 2020, 2:06 AM

replaced createStringError with createFileError, renamed variable.

llvm/tools/llvm-objcopy/MachO/MachOReader.cpp
89

I was referring to the lines 359/360 in MachOObjcopy.cpp

So here you'd simply return Data.takeError() etc,
and in MachOObjcopy.cpp we would have

Expected<std::unique_ptr<Object>> O = Reader.create();
if (!O)
  return createFileError(Config.InputFilename, O.takeError());

if (Error E = handleArgs(Config, **O))
  return createFileError(Config.InputFilename, std::move(E));
avl added inline comments.Sep 24 2020, 2:46 AM
llvm/tools/llvm-objcopy/MachO/MachOReader.cpp
89

got it, thanks.

avl updated this revision to Diff 293993.Sep 24 2020, 3:02 AM

move usage of createFileError at high level.

This revision was automatically updated to reflect the committed changes.
grimar added inline comments.Sep 25 2020, 3:25 AM
llvm/tools/llvm-objcopy/MachO/MachOReader.cpp
91–97

I think DataOrErr was better. Searching of "OrErr" in LLVM code reveals many places (includeing llvm-objcopy code) where such suffic is used for "Expected<>".