Another change of the code design.
Code simplified again, now there is a single place to check
a handler function and less functions for bug report emitting.
More details are added to the bug report messages.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp | ||
---|---|---|
14 | Why do we ignore the return value of checkFunction here? Also, the name doesn't reveal to me why the result is true |
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp | ||
---|---|---|
13–14 | There are problems with this approach in C++ code. | |
14 | The function returns if a problem (warning) was found. At the next call site it is used to display additional notes, but here it is not needed. A better name can be isFunctionValidSignalHandler but the function checks not only a fact, it generates the warnings too. |
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp | ||
---|---|---|
16 | This can probably just be inlined into its only use. | |
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h | ||
36 | This isn't a very descriptive name, and the bool return value conveys no meaning. Probably could do with some documentation. | |
61–63 | While you're refactoring, those static StringSets really belong in the implementation file, and the ConformingFunctions should be a const ref. However global destructores are kind of a taboo thing, Maybe there is case to change them into a sorted array and binary search them to see if a function is conforming. |
Even more simplification, added documentation.
Text of bug reports is more detailed, no NFC now.
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp | ||
---|---|---|
13–14 | The call graph adds nodes for the canonical declaration only. When getting a node it works only with the CanonicalDecl unless the CallGraph code is changed (it seems to be worth to do this change). | |
16 | The value is used now multiple times. (But maybe the diag call can be put into a lambda later.) |
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp | ||
---|---|---|
14 | Can we put (void) checkFunction(...) here to make it clear | |
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h | ||
35–36 | ... as a signal handler | |
36 | Should test the properties ... | |
36–58 | ... from a signal | |
39 | .. from the signal handler ... | |
41 | ... as a registered | |
43 | ... only if a problem ... |
Corrected the comment problems, explained why return value of checkFunction is ignored.
Mostly small nits, but it looks like precommit CI is failing due to the changes:
Failed Tests (2): Clang Tools :: clang-tidy/checkers/bugprone-signal-handler-minimal.c Clang Tools :: clang-tidy/checkers/bugprone-signal-handler-posix.c
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp | ||
---|---|---|
15 | ||
17 | ||
30 | ||
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h | ||
45 |
This generally looks good, and thank you! I have a few minor comments (mostly presentation and documentation).
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp | ||
---|---|---|
13–14 | ||
13–14 | (Nit: There are a lot of indirections in the documentation that did not help understanding what is happening here.) | |
16 | Otherwise, if these are truly const and we are reasonably sure they can be instantiated on any meaningful system without crashing, then these could be a TU-static. It's still iffy, but that technique is used in many places already. | |
16–17 | Perchance this could work with constexpr? Although I'm not sure how widely supported that is, given that we're pegged at C++14 still. | |
18–24 | What does the return value of checkFunction signal to the user, and the if? | |
30 | ||
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h | ||
36–59 | First, we usually call these "diagnostics" in Tidy and not "bug report notes", which to me seems like CSA terminology. Second... It's not clear to me what (from it) is referring to. "[...] show call chain from a signal handler to a [... specific? provided? expected? ...] function" sounds alright to me. | |
42 | ||
61–63 | Once the ConformingFunctions is const, these symbols are not needed here, right? Static initialisation does feel dirty... (heck, there's even a CERT rule against that too!) | |
clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-posix.c | ||
14 | I'm not exactly sure we should call printf (and memcpy) a "system call". As far as I can see, in this patch, isSystemCall() boils down to "declaration in file included as system header" | |
clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c | ||
31 | ||
133 |
Applied the review proposals.
Changed "system call" to "standard function".
Put the string lists into constant std::initializer_list.
Alright, I think this is good to go. I like that it makes it clear that the called function is coming from some external source (system header or otherwise).
This isn't a very descriptive name, and the bool return value conveys no meaning. Probably could do with some documentation.