This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] bugprone-signal-handler: Message improvement and code refactoring.
ClosedPublic

Authored by balazske on Jan 27 2022, 7:49 AM.

Details

Summary

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.

Diff Detail

Event Timeline

balazske created this revision.Jan 27 2022, 7:49 AM
balazske requested review of this revision.Jan 27 2022, 7:49 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 27 2022, 7:49 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
146

Why do we ignore the return value of checkFunction here?

Also, the name doesn't reveal to me why the result is true
or false, e.g. it acts like a predicate but its name doesn't ask
a question.

balazske added inline comments.Jan 27 2022, 9:09 AM
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
146

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.

151

There are problems with this approach in C++ code.

njames93 added inline comments.Jan 27 2022, 9:33 AM
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
167

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.

46–49

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.
Probably wouldn't advise using TableGens StringMatcher to build this functionality as that maybe a little too far.

balazske updated this revision to Diff 404040.Jan 28 2022, 8:28 AM

Even more simplification, added documentation.
Text of bug reports is more detailed, no NFC now.

balazske marked 2 inline comments as done.Jan 28 2022, 8:37 AM
balazske added inline comments.
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
151

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).

167

The value is used now multiple times. (But maybe the diag call can be put into a lambda later.)

balazske retitled this revision from [clang-tidy] bugprone-signal-handler: Code refactor (NFC) to [clang-tidy] bugprone-signal-handler: Message improvement and code refactoring..Jan 28 2022, 8:38 AM
balazske edited the summary of this revision. (Show Details)
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
146

Can we put (void) checkFunction(...) here to make it clear
we're intentionally ignoring the return value?

clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
37

... as a signal handler

38

Should test the properties ...

39–41

... from a signal

42

.. from the signal handler ...

43

... as a registered

45

... only if a problem ...

balazske updated this revision to Diff 404434.Jan 31 2022, 12:36 AM
balazske marked an inline comment as done.

Corrected the comment problems, explained why return value of checkFunction is ignored.

balazske marked 8 inline comments as done.Jan 31 2022, 12:50 AM

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
149
186
201
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
47
balazske updated this revision to Diff 411047.Feb 24 2022, 1:59 AM

Applied review comments, fixed the failing tests.

whisperity added a subscriber: whisperity.

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
72–73

(Nit: There are a lot of indirections in the documentation that did not help understanding what is happening here.)

156–160
162–168

What does the return value of checkFunction signal to the user, and the if?

201
225

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.

225–226

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.

clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
39–42

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.

45
46–49

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 ↗(On Diff #411047)

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 ↗(On Diff #411047)
133 ↗(On Diff #411047)
balazske added inline comments.Mar 3 2022, 2:03 AM
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
156–160

Is this code not too long to put in the condition section?

162–168

This has a description in the header file.

clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-posix.c
14 ↗(On Diff #411047)

Call it "standard function"?

Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2022, 2:03 AM
whisperity added inline comments.Mar 17 2022, 6:32 AM
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
156–160

The formatter will break it up appropriately, no problem with that.

clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-posix.c
14 ↗(On Diff #411047)

Yes, that would be better.

balazske updated this revision to Diff 416429.Mar 18 2022, 2:00 AM

Applied the review proposals.
Changed "system call" to "standard function".
Put the string lists into constant std::initializer_list.

balazske marked 15 inline comments as done.Mar 18 2022, 2:33 AM
balazske updated this revision to Diff 416435.Mar 18 2022, 3:08 AM

Additional documentation related fixes.

balazske marked 2 inline comments as done.Mar 18 2022, 3:10 AM
whisperity accepted this revision.Mar 29 2022, 2:17 AM

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 revision is now accepted and ready to land.Mar 29 2022, 2:17 AM