aaron.ballman added a comment.
While I agree that there's an issue here that needs to be solved, I don't think
this patch will be merged as-is -- there are technical issues brought up by
@alexfh that have not been addressed, and I share the opinion that we should
extend existing suppression mec
davidsj2 added a comment.
I too am interested in this patch. In addition to the use cases already
described, this would be helpful for projects that use several different static
analysis tools and don't want to clutter code with a bunch of different
suppression comments to satisfy each tool.
vlebourl added a comment.
Very interested in this one as well!
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D26418/new/
https://reviews.llvm.org/D26418
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
khoroshansky added a comment.
Herald added a subscriber: danielkiss.
Will this ever be merged?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D26418/new/
https://reviews.llvm.org/D26418
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ht
okainov added a comment.
Any updates on this one? That sounds so fundamental feature which current
version is lacking, it's very frustrating it was not merged yet...
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D26418/new/
https://reviews.llvm.org/D26418
> On Jan 30, 2018, at 7:50 AM, Andrew Peter Marlow via Phabricator via
> cfe-commits wrote:
>
> marlowa added a comment.
>
> In https://reviews.llvm.org/D26418#653146, @nkakuev wrote:
>
>> Ping.
>
>
> another ping. I am desperate for this enhancement and am really glad that
> nkakuev has d
marlowa added a comment.
In https://reviews.llvm.org/D26418#653146, @nkakuev wrote:
> Ping.
another ping. I am desperate for this enhancement and am really glad that
nkakuev has done all the hard development work. I am currently being nobbled in
my use of clang-tidy because the project is usi
alexfh added a comment.
Adding a mechanism to supply suppression lists would be useful as long as it's
flexible and extensible enough and doesn't significantly affect performance
(especially, when not in use). In particular, it shouldn't be bound to a
specific format or a specific way to store
nkakuev added a comment.
Thanks for the response, Alex!
The problem I tried to address in this patch was that notes in source files
were "unsuppressing" warnings from third-party headers (this is what we were
discussing in https://reviews.llvm.org/D26418#590417). But at this point, I no
longe
alexfh added a comment.
My apologies again for the delay. There are a few things I'm concerned about:
1. Suppression list being a command-line option is going to be inconvenient to
completely useless in many setups. The `-line-filter` option is special in this
regard, since it was added for a r
nkakuev added a comment.
Ping.
https://reviews.llvm.org/D26418
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh added a comment.
Sorry for the delay. I'll try to get back to this patch soon.
https://reviews.llvm.org/D26418
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nkakuev added a comment.
Ping.
Ignoring note locations is a coarse-grained solution that will suppress both
false and //true// positives. Suppress-checks-filter is a finer-grained
instrument that can be targetted on particular false positives precisely.
My sympathies are with suppress-checks-f
malcolm.parsons resigned from this revision.
malcolm.parsons removed a reviewer: malcolm.parsons.
malcolm.parsons added a comment.
In https://reviews.llvm.org/D26418#590476, @nkakuev wrote:
> On a second thought, ignoring note locations might be a good enough solution
> for me.
> How should I d
nkakuev added a comment.
In https://reviews.llvm.org/D26418#590417, @malcolm.parsons wrote:
> In https://reviews.llvm.org/D26418#590383, @nkakuev wrote:
>
> > The warning is caused by a third-party code, but header filter won't help
> > you to suppress it since it now relates to your sources.
>
nkakuev added a comment.
In https://reviews.llvm.org/D26418#590417, @malcolm.parsons wrote:
> In https://reviews.llvm.org/D26418#590383, @nkakuev wrote:
>
> > The warning is caused by a third-party code, but header filter won't help
> > you to suppress it since it now relates to your sources.
>
malcolm.parsons added a comment.
In https://reviews.llvm.org/D26418#590383, @nkakuev wrote:
> The warning is caused by a third-party code, but header filter won't help you
> to suppress it since it now relates to your sources.
The header filter suppresses the warning location, but the note loc
nkakuev added a comment.
In https://reviews.llvm.org/D26418#590168, @alexfh wrote:
> What's the biggest complexity with -header-filter? Lack of way to specify
> ? Will it help to make -header-filter a
> GlobList?
See my previous comment. Header filter isn't to help when a (false positive)
wa
nkakuev added a comment.
In https://reviews.llvm.org/D26418#590170, @alexfh wrote:
> I also don't understand the use case for turning off only some checks for
> third-party headers. Either you care about third-party stuff or not, why only
> switch off certain checks?
The use case is ignoring
alexfh added a comment.
I also don't understand the use case for turning off only some checks for
third-party headers. Either you care about third-party stuff or not, why only
switch off certain checks?
https://reviews.llvm.org/D26418
___
cfe-comm
alexfh added a comment.
What's the biggest complexity with -header-filter? Lack of way to specify ? Will it help to make -header-filter a GlobList?
https://reviews.llvm.org/D26418
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.
Eugene.Zelenko added a comment.
I think will be good idea to mention this in documentation and release notes.
https://reviews.llvm.org/D26418
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
22 matches
Mail list logo