[PATCH] D49013: [Support] Allow formatv() to consume llvm::Error by-value without crashing.

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 10 09:04:27 PDT 2018


That seems plausible (op<< for Error) - but does that handle the case
mentioned above "we may not actually want to produce the string (eg: if the
Logger implementation decides to filter out the formatv_object_base based
on level)" - is op<< still called even with this filtering? (seems like if
it was, then it wouldn't avoid the stringification costs? but if it doesn't
call the op<< then it'll still fail the consume semantic requirement of
llvm::Error)

On Tue, Jul 10, 2018 at 7:03 AM Sam McCall via Phabricator <
reviews at reviews.llvm.org> wrote:

> sammccall added a comment.
>
> An alternate approach in https://reviews.llvm.org/D49129: give `Error` an
> overloaded `operator<<` that has the same consume semantics at `toString`
> when passed rvalues.
>
> This makes `formatv`, `to_string`, `toString` all do basically the same
> thing (which is the only sensible thing to do when passed an rvalue).
>
> It does require minor changes to `formatv` and `to_string` to make them
> propagate the right kind of reference, but these seem reasonable.
>
> Overall I think I like that approach better than this one (more
> consistent, Error handling lives in Error.h). WDYT?
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D49013
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180710/0425314a/attachment.html>


More information about the llvm-commits mailing list