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

[Zachary Turner via lldb-commits]

looks good!  Feel free to commit whenever, I'd definitely recommend posting
a PSA on cfe-dev@ (after you commit) so that people know about it.  You
might also get some useful ideas for improvements that way too.

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

> On Thu, Oct 26, 2017 at 5:44 PM, Zachary Turner <zturner at google.com>
> wrote:
>
>>
>>
>> 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*?
>>
>
> Please give it a try, e.g., here are a few I tried:
>
> clangdiag enable covered-switch-default
> clangdiag enable c++11-compat
>
> You can't pass the "-W" part since argparse thinks it's an option (can
> probably fix that if it's a problem), and you must provide the entire
> name.  You can get the available names from diagtool, e.g.:
>
> diagtool list-warnings
>
> Please let me know what you think, and thanks for suggesting it.
>
>
>
>>
>> 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/c66fbf2a/attachment.html>