[Lldb-commits] [PATCH] D36347: New lldb python module for adding diagnostic breakpoints

[Zachary Turner via lldb-commits]

On Thu, Oct 26, 2017 at 3:18 PM Don Hinton <hintonda at gmail.com> wrote:

> On Thu, Oct 26, 2017 at 2:48 PM, Zachary Turner <zturner at google.com>
> wrote:
>
>> Seems fine, it would be nice if the workflow could be improved a little
>> bit so that all you have to do is say `clangdiag break
>> —error=“-Wcovered-switch”` or something . I think that gives the most
>> intuitive usage for people, even it’s a bit harder to implement.
>>
>
> The idea was to break on actual diagnostics emitted, but if you want to
> break on diagnostic usage, i.e., when it was checked but not emitted, I
> suppose that's possible as well.  diagtool doesn't produce a mapping for
> this, but it could be added -- assuming tablegen produced enough info in
> the .inc files to support it.  I added the feature I'm using here a few
> months ago, which was an extension to what Alex added earlier.
>

That was my idea too.  But still, wouldn't it be possible to say `clangdiag
break --error="-Wcovered-switch"` and then have it break only when the
-Wcovered-switch diagnostic is *emitted*?

The reason I keep using this syntax though is because clang developers
always think in terms of the warning names.  If you want to find out why a
warning is being emitted amidst a spew of other warnings and errors, you
really want to be able to specify the name of the warning.

Don't get me wrong though, I do think this is a nice feature, I'm just
thinking of ways to make it more compelling by looking at it from the clang
developer's perspective and how they will most likely want to use it.

Also, I still think it should go in lldb, not in clang.  That's kind of
exactly what the lldb/examples folder is for.

That said, lgtm, but I'm still interested to see if the workflow can be
streamlined down the line.  Perhaps after it gets checked in you can make a
PSA on cfe-dev@ and mention that you want people to try it out and offer
feedback ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20171027/011e2493/attachment.html>