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.
I just pushed this revision, could this be the issue? How recent is your clang?
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)
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