[PATCH] D36347: New lldb python module for adding diagnostic breakpoints
Zachary Turner via cfe-commits
cfe-commits at lists.llvm.org
Thu Oct 26 22:34:27 PDT 2017
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>
>> 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>
>>>> 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...
More information about the cfe-commits