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

[Yitzhak Mandelbaum via cfe-dev]

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/5b6423b3/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/5b6423b3/attachment.bin>