Create a PrettyStackTraceEvent that will dump the current check as well as the bound nodes if a ClangTidyCheck::check call results in a segfault.
This should help massively in debugging random crashes users may be experiencing where the check causing the crash is unknown as well as the source location of the crash.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp | ||
---|---|---|
180 | blank line before onResultEntry |
Refactored implementation to not store state in ClangTidyContext. This will let external consumers of clang-tidy opt into the behaviour. As well as integrate the reporting to any signal handlers they may be using.
Still LGTM and my comments are just thought experiments,
not must haves before pushing.
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp | ||
---|---|---|
165 | Does the LLVM style guide say anything about preferring member initializers over initializing constant expressions? | |
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h | ||
235 | We repeat this if (CurrentlyProcessing) fragment 3 times... |
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h | ||
---|---|---|
235 | I don't think thats an improvement, as if we aren't in a context where the stack trace would be emitted, we don't want to be storing the state on each match. |
clang-tools-extra/test/CMakeLists.txt | ||
---|---|---|
100 | Fairly certain llvm_add_library isnt the correct function to use as that will put the test module in the build/lib directory. However thats what the other plugin module is using so I've copied that for now. |
Ignore the CTCrashTestTrace implementation file in the lit tests, Fixes 'Test has no 'RUN'' error.
@thakis I tried to test this on the gn build and got no issues, however I'm aware that the CTCrashTestTrace plugin isn't even compiled on the gn build. Not sure its worth the effort fixing that. The lit test should be disabled anyway.
LGTM
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp | ||
---|---|---|
165 | I know we document that we prefer sticking with the local style used around the change. I don't know if we say anything about initializers, but for new code I've been suggesting folks use member initializers when possible. | |
349–352 | This function does a whole lot of things that shouldn't be used in signal handlers: http://eel.is/c++draft/support.signal#3 Unless you know of a problem from the assert, I'd say go ahead and use it. |
I have decided to move this behaviour into the ast matcher directly, I feel in the long term, that should be a better home for this functionality.
Please sort alphabetically.