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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
80 ms | x64 windows > LLVM.CodeGen/XCore::threads.ll |
Event Timeline
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 | ||
---|---|---|
400 | Would it make sense to require Handler to be nonnull with an assertion? |
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 | ||
---|---|---|
400 | Wasn't sure which way to go with that one, happy to use an assert if you think it's a good idea |
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 | ||
---|---|---|
400 | Now that I understand the use for this change better, I think the code is good as-is. |
clang-tools-extra/clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
400 | Whoops, just changed it to assert |
clang-tools-extra/clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
400 | 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. |
clang-tools-extra/clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
400 | 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. |
clang-tools-extra/clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
400 | 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. |
clang-tools-extra/clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
400 | With a null handler, we can't capture any test output to validate anything. |
LG!
clang-tools-extra/clang-tidy/ClangTidyOptions.cpp | ||
---|---|---|
400 | 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. |
Would it make sense to require Handler to be nonnull with an assertion?