On Thu, Oct 26, 2017 at 5:44 PM, Zachary Turner <ztur...@google.com> wrote:
> > > On Thu, Oct 26, 2017 at 3:18 PM Don Hinton <hinto...@gmail.com> wrote: > >> On Thu, Oct 26, 2017 at 2:48 PM, Zachary Turner <ztur...@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 ;-) >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
