Page MenuHomePhabricator

[clang-tidy] Fix lint warning in ClangTidyDiagnosticConsumer.cpp (NFC)
ClosedPublic

Authored by salman-javed-nz on Nov 9 2021, 2:07 AM.

Details

Summary

Calling clang-tidy on ClangTidyDiagnosticConsumer.cpp gives a
"unmatched NOLINTBEGIN without a subsequent NOLINTEND" warning.

The "NOLINTBEGIN" and "NOLINTEND" string literals used in the
implementation of createNolintError() get mistaken for actual
NOLINTBEGIN/END comments used to suppress clang-tidy warnings.

Rewrite the string literals so that they can no longer be mistaken for
actual suppression comments.

Diff Detail

Event Timeline

salman-javed-nz created this revision.Nov 9 2021, 2:07 AM
salman-javed-nz requested review of this revision.Nov 9 2021, 2:07 AM
carlosgalvezp added a comment.EditedNov 9 2021, 2:55 AM

Hmm, this sounds a bit hacky. I noticed a similar pattern in tests. I think it deteriorates readability a bit.

Can we make the detection of the tag more robust? Right now we check if a line contains NOLINTBEGIN/END. Why not check if it contains // NOLINTBEGIN? (// as part of the line).

salman-javed-nz added a comment.EditedNov 9 2021, 3:37 AM

clang-tidy looking for NOLINT markers but not checking to see that the marker is within a comment, is long-standing behaviour at this point.
cpplint has the same behaviour, which explains why clang-tidy's implementation started off this way.

That's not to say that we have to keep this way forever. I would love for it to be improved.

However, discussing what the new behaviour should be and delivering it is beyond the scope of this patch, which is just trying to fix lint warnings in the meantime with the current day NOLINT framework.

salman-javed-nz added a comment.EditedNov 9 2021, 3:43 AM

I suspect that ensuring that NOLINTs are within a comment could be a reasonably large code change. If it is to be robust with /* multiline comments */ and \ characters and other shenanigans, then I would probably lean on the compiler to tell us what is and isn't a comment, instead of the simple text search approach we currently have.

If it is to be robust with /* multiline comments */

Does it have to be? I don't recall that we have unit tests for that. I would personally restrict the usage to only one way to write the line. I think it's not hard for users to adapt to that, plus it encourage them to write more readable code.

But OK, since it can potentially be a large change let's leave it for another time.

carlosgalvezp accepted this revision.Nov 9 2021, 3:53 AM
This revision is now accepted and ready to land.Nov 9 2021, 3:53 AM

Thanks for the review.

I will think some more about your suggestion to look for //. Once I have something that works, I will be back for another review.

Great! I'd be open to supporting /* as well if people really need it. But so far that use case is not documented nor tested, so I think we shouldn't add new functionality if it's not needed. It can be added in the future if someone has a compelling case.

akuegel added inline comments.
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
387

tooling::DiagnosticMessage expects a StringRef. If you pass it a str() from a local string, this can lead to bad pointers.

jgorbe added a subscriber: jgorbe.Nov 9 2021, 11:03 AM

This change is causing asan errors when running the clang-tidy checks under ASan, most likely because of the reason akuegel pointed out in his comment. I'm going to revert the patch to unbreak HEAD until the problem can be fixed.

This change is causing asan errors when running the clang-tidy checks under ASan, most likely because of the reason akuegel pointed out in his comment. I'm going to revert the patch to unbreak HEAD until the problem can be fixed.

If you could do that, that would be appreciated. Thank you. I won't be able to get back to my desk to revert myself for at least half an hour.

Revert to using simple string literals. I was being too clever for my own good with the Twine.
I think this should no longer cause ASan issues. WDYT?

This was meant to be a simple patch, so sorry for all the trouble.