[cfe-dev] [clang-tidy] Excluding individual files/lines from clang-tidy checks

[Nikita via cfe-dev]

No, currently I cannot see a reasonable way to handle this situation.
Probably, line ranges are unnecessary. But suppressing certain checks
from entire files is still useful for filtering out false positives.

I can omit line ranges and make '--suppress-warnings-from' take only
file names and checks: [{"name":"header.h","checks":"cert-*"}].

Does this look good now?

On Thu, Nov 3, 2016 at 4:49 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
>> On Nov 2, 2016, at 4:42 PM, Nikita via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>
>> I think I'll explain why I need this functionality and why I think it
>> would be useful for others.
>>
>> Currently clang-tidy doesn't provide a practical way to suppress
>> diagnostics from headers you don't have control over. If using a
>> function defined in such header causes a false positive, there is no
>> easy way to deal with this issue. Since you cannot modify a header,
>> you cannot add NOLINT to it. And adding NOLINT to each invocation of
>> such function is either impossible or hugely impractical if
>> invocations are ubiquitous.
>>
>> Using the '-header-filter' doesn't help to address this issue as well.
>> Unless your own headers are strategically named, it is virtually
>> impossible to craft a regex that will filter out only the third-party
>> ones.
>>
>> The '-line-filter' can be used to suppress such warnings, but it's not
>> very convenient. Instead of excluding a line that produces a warning
>> you have to include all other lines. Plus, it provides no way to
>> suppress only certain warnings from a file.
>>
>> With all this mentioned, I think that clang-tidy would benefit from a
>> mechanism that is specifically designed to suppress certain warnings
>> from certain lines in a convenient way.
>
> That causes some maintainability issues though: let say I filter something between line 1000 and 1005 today, what if some code is later added before?
> Do you see a way of handling this?
>
> —
> Mehdi
>
>
>>
>> I don't see how existing options can be changed to provide this
>> functionality, so I propose adding a new option -
>> '--exclude-from-checks' - that will take a list of locations to
>> suppress warnings from. It can additionally take a list of checks to
>> suppress. The format of its' argument can be a JSON array similar to
>> the one '-line-filter' takes:
>> [{"name":"header.h","lines":[[1,5]],"checks":"cert-*"}].
>>
>> I would gladly appreciate any feedback on this idea and look forward
>> to the discussion.
>>
>> Regards,
>> Nikita
>>
>> On Sat, Oct 29, 2016 at 12:11 AM, Nikita <nikita.kakuev at gmail.com> wrote:
>>> Well, I'm trying to mimic the behavior of '-line-filter'. But I also
>>> think that JSON is cumbersome. It requires putting arguments in
>>> quotes, plus the format itself seems a bit redundant. Specifying
>>> '[{"name":"file.h"}]' without the line range seemingly does nothing.
>>> Diagnostics for "file.h" will be emitted even without this filter.
>>>
>>> On Fri, Oct 28, 2016 at 11:52 PM, Richard via cfe-dev
>>> <cfe-dev at lists.llvm.org> wrote:
>>>>
>>>> [Please reply *only* to the list and do not include my email directly
>>>> in the To: or Cc: of your reply; otherwise I will not see your reply.
>>>> Thanks.]
>>>>
>>>> In article <CAGJfN2yb=3D-oCyTycsULN7F=Gn=KxFW_O4r4ndzCd8bFZ2muw at mail.gmail.com>,
>>>>    Nikita via cfe-dev <cfe-dev at lists.llvm.org> writes:
>>>>
>>>>>> clang-tidy '-exclude-from-checks=[{"name":"exclude.c","lines":[[5,7]]}]'
>>>>
>>>> Why are we specifying command-line arguments as JSON?
>>>>
>>>> It seems unnecessarily cumbersome to me.
>>>> --
>>>> "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
>>>>            The Terminals Wiki <http://terminals-wiki.org>
>>>>     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
>>>>  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>