[cfe-dev] clang tidy: multiple diagnostics for a single source location?

Yitzhak Mandelbaum via cfe-dev cfe-dev at lists.llvm.org
Fri Aug 23 11:04:23 PDT 2019


never mind to that last question -- it's obvious from the fields of the
struct.  But, that begs the question: should the deduping really be
ignoring the associated fixes (that is, the `Fix` field)?

On Fri, Aug 23, 2019 at 1:44 PM Yitzhak Mandelbaum <yitzhakm at google.com>
wrote:

> Thanks! That code is indeed the problem, but not because of your revision.
> Fundamentally, the comparison does not take the fixes into account, which
> causes the problem I'm experiencing.  This makes sense, except that the
> tidy check is emitting a diagnostic for two different *expanded* locations
> which are getting mapped back to the same expansion loc and, hence, being
> lost in the dedupe.  As far as I can tell, the lossiness is happening here:
>
> clang/lib/Frontend/DiagnosticRenderer.cpp, lines 118-127
>
> which normalizes the reported location with SourceManager::getFileLoc()
> before saving it in a DiagnosticMessage.  Do you know why the
> DiagnosticMessage requires that its location be in a file?
> (clang/include/clang/Tooling/Core/Diagnostic.h, line 37)
>
> On Fri, Aug 23, 2019 at 11:43 AM Kristóf Umann <dkszelethus at gmail.com>
> wrote:
>
>> Hi!
>>
>> I just pushed this revision, could this be the issue? How recent is your
>> clang?
>> https://reviews.llvm.org/D65065
>>
>> + Tibor Brunner
>>
>> Cheers,
>> Kristóf
>>
>> On Fri, 23 Aug 2019, 17:39 Yitzhak Mandelbaum via cfe-dev, <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> I've hit a case where a clang-tidy check is losing a diagnostic (w/
>>> associated fix) when its associated location is the same as an earlier
>>> diagnostic. This happens even when the fix itself changes a different
>>> source range.
>>>
>>> Is this working-as-intended? If so, is there any way to get clang-tidy
>>> to warn about the dropped fix, rather than dropping it silently? If not,
>>> any pointers to where this might be happening would be appreciated.
>>>
>>> Thanks,
>>> Yitzhak
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190823/bc80cfe0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4847 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190823/bc80cfe0/attachment.bin>


More information about the cfe-dev mailing list