Page MenuHomePhabricator

[Clang][Bundler] Error reporting improvements
ClosedPublic

Authored by sdmitriev on Aug 30 2019, 8:01 PM.

Details

Summary
  • Changed FileHandler read/write methods to return llvm::Error
  • Using unified way of reporting errors
  • Removed trailing '.' from the error messages

Diff Detail

Event Timeline

sdmitriev created this revision.Aug 30 2019, 8:01 PM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: cfe-commits. · View Herald Transcript

This changes error messages, so I'd say it's not NFC.

clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
42–45

The code still uses (in the order of marked includes)

  • std::unique_ptr
  • std::string
  • std::error_code
  • std::vector,

so I don't think these lines should be removed. Same goes for assert and probably also cstddef / cstdint (uint64_t?)

sdmitriev updated this revision to Diff 218224.Aug 31 2019, 9:10 AM
sdmitriev retitled this revision from [Clang][Bundler] Error reporting improvements [NFC] to [Clang][Bundler] Error reporting improvements.

Addressed review comments.

sdmitriev marked an inline comment as done.Aug 31 2019, 9:12 AM
sdmitriev added inline comments.
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
42–45

Right. Restored required system includes.

MaskRay added inline comments.
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
898

I think trailing full stop is uncommon in error messages.

sdmitriev marked an inline comment as done.Aug 31 2019, 11:01 AM
sdmitriev added inline comments.
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
898

Maybe., but all error messages in this tool seem to be consistent in that sense)) Do you suggest removing trailing '.' from all error messages?

sdmitriev updated this revision to Diff 218250.Aug 31 2019, 6:47 PM

Removed trailing '.' from error messages and added few additional changes for better error handling.

sdmitriev marked an inline comment as done.Sep 4 2019, 11:04 AM

Any comments?

Hahnfeld added inline comments.Sep 4 2019, 11:13 AM
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
42–45

vector is still removed which is definitely used. Are you 100% sure that algorithm and cstddef are not needed?

sdmitriev marked an inline comment as done.Sep 4 2019, 11:21 AM
sdmitriev added inline comments.
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
42–45

I have replaced all uses of vector with SmallVector.

Are you 100% sure that algorithm and cstddef are not needed?

Ok, I will add algorithm and cstddef back:)

sdmitriev updated this revision to Diff 218755.Sep 4 2019, 11:25 AM

Also, there should be a summary of the changes in here.

clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
42–45

If you want to replace vector by SmallVector, this must be its own revision.

sdmitriev marked an inline comment as done.Sep 4 2019, 12:24 PM
sdmitriev added inline comments.
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
42–45

Must? Can you show any document/link explaining this?
I have no problem with doing that in a separate commit, not a big deal, just want to see why it has to be done that way.

Hahnfeld added inline comments.Sep 4 2019, 12:32 PM
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
42–45

This is common practice for reviews: Only one change per patch and split into smaller patches if possible and logically appropriate.

I can't quote a written requirement, but the Developer Policy section about code reviews mentions splitting patches and there's a whole section about Incremental Development.

sdmitriev updated this revision to Diff 218776.Sep 4 2019, 1:11 PM
sdmitriev edited the summary of this revision. (Show Details)
sdmitriev marked an inline comment as done.
sdmitriev added inline comments.
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
42–45

I have reverted vector -> SmallVector change.

I think I have addressed all comments posted so far. Do you have more notes/comments/suggestions?

sdmitriev added a reviewer: Hahnfeld.

Rebase

ABataev added inline comments.Oct 2 2019, 11:43 AM
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
132–136

Do we really need an inner Optional here?

sdmitriev added inline comments.Oct 2 2019, 2:21 PM
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
132–136

The idea was to return StringRef with bundle name when we have still have bundles and None when there are no more bundles in the file (BTW comment has to be updated to describe this). But I can restore the old convention where empty bundle name means 'no more bundles' in the file. In terms of functionality that would be the same, though use of Optional<...> makes intentions more explicit))

sdmitriev updated this revision to Diff 224726.Oct 11 2019, 8:06 PM

Rebased patch.

sdmitriev added inline comments.Oct 11 2019, 8:15 PM
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
132–136

I have updated comment to describe the intended behavior.
@ABataev do you insist on removing inner Optional<> and restoring the current convention where empty string means the end of bundles in the file?

ABataev added inline comments.Oct 14 2019, 7:15 AM
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
132–136

The problem here is that Expected already handles the state and we have inner Optional for the same reason. Can we reuse Expected to indicate that there are no more bundles?

sdmitriev added inline comments.Oct 22 2019, 10:28 PM
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
132–136

Well, Expected encodes two possible states (either Error or Value), but we need to encode three states - Error, Value or None. I do not have ideas how to do it without adding inner Optional. If you have, please share.

This revision is now accepted and ready to land.Oct 25 2019, 8:02 AM
This revision was automatically updated to reflect the committed changes.