clang tidy: multiple diagnostics for a single source location?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

clang tidy: multiple diagnostics for a single source location?

Kristóf Umann via cfe-dev
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: clang tidy: multiple diagnostics for a single source location?

Kristóf Umann via cfe-dev
Hi!

I just pushed this revision, could this be the issue? How recent is your clang?

+ Tibor Brunner

Cheers,
Kristóf

On Fri, 23 Aug 2019, 17:39 Yitzhak Mandelbaum via cfe-dev, <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang tidy: multiple diagnostics for a single source location?

Kristóf Umann 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 <[hidden email]> wrote:
Hi!

I just pushed this revision, could this be the issue? How recent is your clang?

+ Tibor Brunner

Cheers,
Kristóf

On Fri, 23 Aug 2019, 17:39 Yitzhak Mandelbaum via cfe-dev, <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: clang tidy: multiple diagnostics for a single source location?

Kristóf Umann via cfe-dev
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 <[hidden email]> 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 <[hidden email]> wrote:
Hi!

I just pushed this revision, could this be the issue? How recent is your clang?

+ Tibor Brunner

Cheers,
Kristóf

On Fri, 23 Aug 2019, 17:39 Yitzhak Mandelbaum via cfe-dev, <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

smime.p7s (6K) Download Attachment