This is an archive of the discontinued LLVM Phabricator instance.

FileManager: Use llvm::Expected in new getFileRef API
ClosedPublic

Authored by dexonsmith on Aug 24 2019, 8:20 AM.

Details

Reviewers
arphaman
lhames
Summary

FileManager::getFileRef is a modern API which we expect to convert to
over time. We should modernize the error handling as well, using
llvm::Expected instead of llvm::ErrorOr, to help clients that care
about errors to ensure nothing is missed.

However, not all clients care. I've also added another path for those
that don't:

  • FileEntryRef is now copy- and move-assignable (using a pointer instead of a reference).
  • FileManager::getOptionalFileRef returns an llvm::Optional instead of llvm::Expected.
  • Added an llvm::expectedToOptional utility in case this is useful elsewhere.

Diff Detail

Event Timeline

dexonsmith created this revision.Aug 24 2019, 8:20 AM

@arphaman, is there a reason you think ErrorOr is more appropriate long-term here?

arphaman added inline comments.Aug 24 2019, 8:28 AM
clang/lib/Lex/HeaderSearch.cpp
1081

It should be fine to update the return type, but I believe that Expected will cause an assertion as the error is unhandled in cases like this one. Can you verify that all errors are consumed somehow?

dexonsmith edited the summary of this revision. (Show Details)
dexonsmith added a subscriber: lhames.

Updated patch after running check-clang and learning more about Expected. I've added a parallel API using Optional<FileEntryRef> for clients that don't want to do anything with the error.

@lhames, is it reasonable to add llvm::expectedToOptional?

Herald added a project: Restricted Project. · View Herald TranscriptAug 24 2019, 11:47 AM
dexonsmith marked 2 inline comments as done.Aug 24 2019, 11:52 AM
dexonsmith added inline comments.
clang/lib/Lex/HeaderSearch.cpp
1081

Yup, when the tests finished running I saw that I'd misunderstood how Expected::operator bool works.

For the users that don't care about the errors, consuming them is harmful boilerplate. I've switched to a split API that either returns Expected or Optional. This way clients that do care get the assertions if they mishandle it, and the clients that don't annotate that at the call site. WDYT?

dexonsmith marked an inline comment as done.
dexonsmith edited the summary of this revision. (Show Details)

Also update FileEntryRef to be copy- and move-assignable so that Optional<FileEntryRef> can be assigned to.

dexonsmith edited the summary of this revision. (Show Details)

Fix the change to CompilerInstance.cpp.

Updated patch after running check-clang and learning more about Expected. I've added a parallel API using Optional<FileEntryRef> for clients that don't want to do anything with the error.

@lhames, is it reasonable to add llvm::expectedToOptional?

Absolutely: We've already got an errorToBool, so expectedToOptional makes sense.

This revision is now accepted and ready to land.Aug 26 2019, 10:21 AM