[lldb-dev] logging in lldb

[Jim Ingham via lldb-dev]

> On Dec 6, 2016, at 10:07 AM, Zachary Turner <zturner at google.com> wrote:
> 
> Merging the thread over from lldb-commits:
> 
> 
> 
> On Tue, Dec 6, 2016 at 9:57 AM Jim Ingham via Phabricator <reviews at reviews.llvm.org> wrote:
> jingham added a comment.
> 
> I not infrequently have some non-trivial code in the "if (log)" block that gathers the information that I am then going to print, or loops over entities printing them.  Putting more complex code like that inside a macro looks awful and is hard to debug.  I don't think that argues for not using the macros in the case where you are logging a simple string, but it does argue for keeping the old way available.
> Not arguing against keeping the old way possible, but as an aside, llvm::formatv() can handle many of these cases pretty nicely.
> 
> For starters, it has builtin support for formatting ranges.  So if you're ever looping over entities formatting them, as long as the entity itself has a formatter defined, you can simply pass it directly to formatv and it will do the right thing.  (It has some customization support built in as well so you can control how to separate items).
> 
> Secondly, When you have to do some work to get the value you want to format, you could either define a custom formatter for the type in question, and the formatter does all the work, or you could write a function to return the value you want to format, and call that in the argument list, as long as the return type has an associated formatter.
> 
> I'm sure there will still be cases where you want to use the old method, but I think this would handle quite a few of them and reduce the amount of code you have to read / write when dealing with logging code.

I have had to do the "where the heck does this log line come from in the code" search many many times debugging external reports.  I worry a bit that anything that makes output more magical as you are suggesting also makes this task harder.  Again, IME you will write log code fairly infrequently, but you will grub around trying to figure out what the logs mean quite frequently.  So you always want to optimize for easy of use rather than of emission.

That being said, the formatv stuff does sound pretty cool.

Jim