[Lldb-commits] [PATCH] D43912: [Symbol] Add InvalidType, a force-checked recoverable error

[Adrian Prantl via lldb-commits]

> On Mar 1, 2018, at 10:44 AM, Pavel Labath <labath at google.com> wrote:
> 
> On 1 March 2018 at 10:34, Adrian Prantl <aprantl at apple.com> wrote:
>> 
>>> On Mar 1, 2018, at 10:25 AM, Jim Ingham <jingham at apple.com> wrote:
>>> 
>>> I have no general objections to macros, and reducing boiler-plate is good.  They do get in the way of debugging because of the weird C rule that a macro has to pretend that it is all one source line, so if they contain code you are interested in stopping at, there needs to be some other way to do that.  But provided that's taken care of, they are fine.
>> 
>> I believe the only thing that needs to be in a macro is the return, and all the other lines could be factored out into a helper function, in which you could then break, and it would reduce code size. Hmm.. if you can factor out the rest into a (templated) function, we probably don't even need to make this a macro:
>> 
>> if (takeAndLogError(item))
>>  return Error();
>> 
> 
> The main reason we have these macros is that most or our logging
> statements were doing something like
> log->Printf("MyClassName::%s: blah blah...", __FUNCTION__);
> The idea was that the macro could substitute these automatically (the
> macro can't get at the class name, so it prints the file name instead,
> which is generally close enough).
> If we are fine with not having this source information, then we don't
> need the macros. That said, I think it's useful having information
> about where a particular log message came from..

Thanks, I missed the __FUNCTION__ part! I guess you could still define a minimal macro as

#define takeAndLogError(ITEM) \
  takeAndLogErrorImpl(__FUNCTION__, item)

-- adrian