This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Add a diagnostic callback to parseConfiguration
ClosedPublic

Authored by njames93 on Dec 9 2020, 1:33 AM.

Details

Summary

Currently errors detected when parsing the YAML for .clang-tidy files are always printed to errs.
For clang-tidy binary workflows this usually isn't an issue, but using clang-tidy as a library for integrations may want to handle displaying those errors in their own specific way.

Diff Detail

Event Timeline

njames93 created this revision.Dec 9 2020, 1:33 AM
njames93 requested review of this revision.Dec 9 2020, 1:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 9 2020, 1:33 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
njames93 updated this revision to Diff 310476.Dec 9 2020, 3:06 AM

Use MemoryBufferRef instead of StringRef so the Diagnostic can have a meaningful filename.

Nothing is calling the new parseConfigurationWithDiags(), is that intentional? Also, is there a way to add test coverage for the change?

clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
401

Would it make sense to require Handler to be nonnull with an assertion?

Nothing is calling the new parseConfigurationWithDiags(), is that intentional? Also, is there a way to add test coverage for the change?

Yes it is intentional, the idea is for programs embedding clang-tidy to use this interface if they wish to handle diagnostics from parsing themselves.

Tests could be added

clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
401

Wasn't sure which way to go with that one, happy to use an assert if you think it's a good idea

Nothing is calling the new parseConfigurationWithDiags(), is that intentional? Also, is there a way to add test coverage for the change?

Yes it is intentional, the idea is for programs embedding clang-tidy to use this interface if they wish to handle diagnostics from parsing themselves.

Ahh, I see, thank you for the explanation.

Tests could be added

I think they should be added.

clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
401

Now that I understand the use for this change better, I think the code is good as-is.

njames93 updated this revision to Diff 310894.Dec 10 2020, 7:50 AM

Added test cases.
Added assert to ensure Handler is valid.

njames93 marked an inline comment as done.Dec 10 2020, 7:51 AM
njames93 added inline comments.
clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
401

Whoops, just changed it to assert

aaron.ballman added inline comments.Dec 10 2020, 8:19 AM
clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
401

Heh, sorry about that! Before changing it again, let's make sure we agree. My thinking is: this is a general API (rather than a specific one only to be used internally) and not every caller may care about reporting diagnostics; the error return code is sufficient to tell any caller whether the parsing was successful or not.

njames93 added inline comments.Dec 10 2020, 1:20 PM
clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
401

That's pretty much it, For external users. If they don't care about capturing the diagnostics then the parseConfiguration function should be used. If they do care and call this new function with an empty callable, they have probably made a mistake.

njames93 updated this revision to Diff 311391.Dec 12 2020, 6:49 AM

Fix up test case now bug in yaml error locations has been fixed

aaron.ballman added inline comments.Dec 15 2020, 11:31 AM
clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
401

Okay, then I apologize for the churn, but can you go back to accepting a null input (and a test case for it)? With that, I think the patch LG.

njames93 added inline comments.Dec 15 2020, 5:15 PM
clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
401

With a null handler, we can't capture any test output to validate anything.

njames93 updated this revision to Diff 312080.Dec 15 2020, 5:15 PM

Added back null check

aaron.ballman accepted this revision.Dec 16 2020, 5:09 AM

LG!

clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
401

I meant more just to demonstrate that it's a supported part of the interface and won't crash, assert, or do bad things. If you don't think it will be that useful, I don't insist.

This revision is now accepted and ready to land.Dec 16 2020, 5:09 AM
This revision was landed with ongoing or failed builds.Dec 16 2020, 4:25 PM
This revision was automatically updated to reflect the committed changes.