This is an archive of the discontinued LLVM Phabricator instance.

[yaml2obj/ObjectYAML] - Cleanup the error reporting API, add custom errors handlers.
ClosedPublic

Authored by grimar on Sep 11 2019, 7:12 AM.

Details

Summary

This is a continuation of the YAML library error reporting
refactoring/improvement and the idea by itself was mentioned
in the following thread:
https://reviews.llvm.org/D67182?id=218714#inline-603404

This performs a cleanup of all object emitters in the library.
It allows using the custom one provided by the caller.

One of the nice things is that each tool can now print its tool name,
e.g: "yaml2obj: error: <text>"

Also, the code became a bit simpler.

Diff Detail

Event Timeline

grimar created this revision.Sep 11 2019, 7:12 AM
sbc100 added inline comments.Sep 11 2019, 7:34 AM
include/llvm/ObjectYAML/yaml2obj.h
49

It seems like there is a separate change here which is to convert a lot of return codes from "int -> 0 for success" to "bool -> 1 for success". Is that objectively better? Is there an llvm policy for which is preferred? Could this change be more precise if that part was split out?

lib/ObjectYAML/yaml2obj.cpp
21

I don't see this function referenced anywhere.

grimar marked 2 inline comments as done.Sep 11 2019, 7:44 AM
grimar added inline comments.
include/llvm/ObjectYAML/yaml2obj.h
49

I believe it is better because we only use 1 and 0. There are no another values => the valid type to represent it should be bool. I never heard about policies about the returning types in the libraries. And it is a bit hard to imagine one that would say to use int when we can use bool :)

I am OK to split it out I think, I am not sure if it can make this diff much shorter/easier to read, but I'll try.

lib/ObjectYAML/yaml2obj.cpp
21

Oh, you're right, thanks. I forgot to remove it. At first I experimenmted with the logic that used a default handler if no handler was provided, but then removed it. It seems that it is OK to always provide the custom one.

Broadly looks fine to me.

include/llvm/ObjectYAML/yaml2obj.h
47

using instead of typedef maybe?

lib/ObjectYAML/MachOEmitter.cpp
18

I haven't yet looked at the other files, but this seems like an unnecessary include, right?

lib/ObjectYAML/WasmEmitter.cpp
130

clang-format?

unittests/ObjectYAML/YAML2ObjTest.cpp
60

Delete "the"

69

Delete "the"

82

No newline at end of file

sbc100 added inline comments.Sep 11 2019, 8:15 AM
include/llvm/ObjectYAML/yaml2obj.h
49

I think its mostly a split between the old school C-style APIs where zero means success and non-zero means failure. I'm not sure how relevant this is in modern C++ codebases though.. perhaps not at all.

MaskRay added inline comments.Sep 12 2019, 2:32 AM
lib/ObjectYAML/COFFEmitter.cpp
84

I see is below so I'm thinking whether we should use gets here.

lib/ObjectYAML/MachOEmitter.cpp
390

Probably make a separate change to convert typedef to using.

test/tools/yaml2obj/dynsymtab-implicit-sections-size-content.yaml
34

yaml2obj: is prepended to a few error messages. In llvm-readobj/llvm-objcopy/llvm-objdump, I think we leave out the tool name?

tools/yaml2obj/yaml2obj.cpp
56

or failed to open.

failed to parse is used in yaml2coff.

unittests/ObjectYAML/YAML2ObjTest.cpp
77

Res can be deleted.

grimar updated this revision to Diff 219877.Sep 12 2019, 3:42 AM
grimar marked 22 inline comments as done.
  • Addressed review comments.
  • Now rebased on top of D67488.
include/llvm/ObjectYAML/yaml2obj.h
47

Ok.

lib/ObjectYAML/COFFEmitter.cpp
84

I guess both of spellings make sense. But these messages are far from ideal. I think reporting "section alignment is too large" or "string table is/got too large" without mentioning at least the name of a section is not too usefull anyways. I'd leave them alone for now.

lib/ObjectYAML/MachOEmitter.cpp
18

Yes, removed.

390

LLVM heavily uses typedefs too, so I guess it is not a real problem.
New code probably should use using though.

lib/ObjectYAML/WasmEmitter.cpp
130

Yep.

test/tools/yaml2obj/dynsymtab-implicit-sections-size-content.yaml
34

I added it here because test on the left had "yaml2obj failed" message and now we do not have it.
So I wanted to show the whole difference.
Generally I think we should not include testing of the tool name everywhere.

I added it to tests like "invalid-docnum.test" and "empty-or-invalid-doc.yaml" below though, since they
test the basic functionality and reporting the tool name is a basic thing that should be checked at least for basic messages perhaps.

But generally I do not have a strong feeling about how we should test this, so can remove it, though do not see a problem to keep it too.

tools/yaml2obj/yaml2obj.cpp
56

Ok.

unittests/ObjectYAML/YAML2ObjTest.cpp
77

Probably not, because we want to test that convertYAML doesn't return true when there are errors.

jhenderson accepted this revision.Sep 12 2019, 3:55 AM

LGTM, but best wait for others to confirm they're happy.

This revision is now accepted and ready to land.Sep 12 2019, 3:55 AM
MaskRay accepted this revision.Sep 12 2019, 4:01 AM
sbc100 added inline comments.Sep 12 2019, 10:02 AM
lib/ObjectYAML/MachOEmitter.cpp
70

So it seems like this isn't quiet a NFC since the writers in general now always continue to try to write part of the object file even after an error occurs? This seems slightly worse, although I can't think of case where it would be real problem. Assuming that is the desired effect and the consequences have been considered then I'm OK with change in general since it does seem the make the core simpler.

grimar marked an inline comment as done.Sep 13 2019, 1:15 AM
grimar added inline comments.
lib/ObjectYAML/MachOEmitter.cpp
70

So it seems like this isn't quiet a NFC since the writers in general now always continue to try to write part of the object file even after an error occurs?

For now this change is NFC, because writers never return anything rather than Error::success().
If we will need to stop writing on error in future, we might add something like

if (HasError)
  return;

to any place we want.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptSep 13 2019, 8:59 AM