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

[Don Hinton via cfe-commits]

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/cfe-commits/attachments/20171026/fa659836/attachment.html>