We do not need it. I replaced it with
reportError(StringRef Input, Error Err)
almost without problems.
Details
Diff Detail
Event Timeline
tools/llvm-readobj/COFFDumper.cpp | ||
---|---|---|
1942–1943 | reportError(..., codeview::visitTypeStream(..)) | |
tools/llvm-readobj/ELFDumper.cpp | ||
4419 | if (Err) can be deleted | |
4431 | if (Err) can be deleted | |
tools/llvm-readobj/llvm-readobj.cpp | ||
385–386 | reportError now checks if (!Err). Is it still appropriate to call it reportError? I want to hear other opinions. |
tools/llvm-readobj/llvm-readobj.cpp | ||
---|---|---|
385–386 | Previously error(Error EC) did that. I can probably remove if (!Err) check to avoid the confusion. |
tools/llvm-readobj/llvm-readobj.cpp | ||
---|---|---|
385–386 | I'd probably replace the if (!Err) check with an equivalent assertion. I think it's natural to write code like: if (Error E = doSomething()) reportError(File, std::move(E)); whereas the following looks weird to me: reportError(doSomethingWhichWillSucceed()); An alternative name might be "checkError" if you didn't do that. |
tools/llvm-readobj/llvm-readobj.cpp | ||
---|---|---|
385–386 | checkError looks good to me. |
tools/llvm-readobj/llvm-readobj.cpp | ||
---|---|---|
385–386 | I'd probably stick to reportError version. It looks simpler and more natural to use for me. |
tools/llvm-readobj/llvm-readobj.cpp | ||
---|---|---|
385–386 | I think I slightly prefer Error being the first argument. This allows to use default arguments for other fields if we supply more arguments, e.g.: checkError(Error E, StringRef FileName, StringRef ArchiveName, StringRef ArchitectureName = StringRef()); |
- Updated in according to the discussion.
tools/llvm-readobj/llvm-readobj.cpp | ||
---|---|---|
385–386 | Ok, I made Error to be the first argument. I keeped reportError name and added an assert if (Err) reportError(Err, ...); |
tools/llvm-readobj/COFFDumper.cpp | ||
---|---|---|
1170 | Will also replace auto with an explicit type. |
Is EC an Error or std::error_code? If the latter, the move below is unnecessary.