This is an archive of the discontinued LLVM Phabricator instance.

[llvm-readelf/obj] - Minor cleanup of warning reporting.
AbandonedPublic

Authored by grimar on Dec 10 2020, 3:25 AM.

Details

Summary

This:

  1. Removes the reportUniqueWarning overload that accepts Error Err.

We can live with the version that accepts const Twine & and
anyways warnings reported in many places touched by this patch can probably
be improved. To do that we would need to use Twine version anyways.

  1. Converts the last reportWarning in ELFDumper.cpp to reportUniqueWarning.

In that place it is a no-op I believe.

Diff Detail

Event Timeline

grimar created this revision.Dec 10 2020, 3:25 AM
grimar requested review of this revision.Dec 10 2020, 3:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 10 2020, 3:25 AM

Is this desired? For

reportUniqueWarning(
          "SHT_DYNSYM section header and DT_SYMTAB disagree about "
          "the location of the dynamic symbol table");

it is fine. But for the others, a bunch of toString are added.

grimar added a comment.EditedDec 10 2020, 10:54 PM

Is this desired? For

reportUniqueWarning(
          "SHT_DYNSYM section header and DT_SYMTAB disagree about "
          "the location of the dynamic symbol table");

it is fine. But for the others, a bunch of toString are added.

It cleans up the API, leaving the single reportUniqueWarning(const Twine &Msg) method.
This method has different enough signature from regular global reportWarning.
It should help to encourage people to use toString and provide more context for error messages.

Generally I think that lines like
this->reportUniqueWarning(toString(SymsOrErr.takeError())); are not ideal.
Because most of the time messages could be better if they were like:
`this->reportUniqueWarning("some context here: " + toString(SymsOrErr.takeError()));`

I think a context could be added for many if not all of of places touched.

Is this desired? For

reportUniqueWarning(
          "SHT_DYNSYM section header and DT_SYMTAB disagree about "
          "the location of the dynamic symbol table");

it is fine. But for the others, a bunch of toString are added.

It cleans up the API, leaving the single reportUniqueWarning(const Twine &Msg) method.
This method has different enough signature from regular global reportWarning.
It should help to encourage people to use toString and provide more context for error messages.

Generally I think that lines like
this->reportUniqueWarning(toString(SymsOrErr.takeError())); are not ideal.
Because most of the time messages could be better if they were like:
`this->reportUniqueWarning("some context here: " + toString(SymsOrErr.takeError()));`

I think a context could be added for many if not all of of places touched.

It seems to me like having both APIs is useful - there are occasions when there is no need to add additional context, and other occasions where there is. I think we should use whichever approach is suitable for the given situation. For example, the version definition one in printVersionDependencySection is calling a method with the same parameters as the calling code - there is no additional context that the calling code can usefully provide that the callee which returned the error couldn't, so it just has to call toString.

grimar abandoned this revision.Dec 13 2020, 10:58 PM

Abandoning basing on comments.