[PATCH] D93021: [llvm-readelf/obj] - Minor cleanup of warning reporting.

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 11 05:51:41 PST 2020


jhenderson added a comment.

In D93021#2447909 <https://reviews.llvm.org/D93021#2447909>, @grimar wrote:

> In D93021#2446766 <https://reviews.llvm.org/D93021#2446766>, @MaskRay wrote:
>
>> 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`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93021/new/

https://reviews.llvm.org/D93021



More information about the llvm-commits mailing list