[PATCH] D36347: New lldb python module for adding diagnostic breakpoints
Don Hinton via cfe-commits
cfe-commits at lists.llvm.org
Thu Oct 26 21:52:52 PDT 2017
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>
>>> 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.:
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