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
14

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

njames93 added inline comments.Jan 27 2022, 9:33 AM
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.
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
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.)

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
14

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

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
15
17
30
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
45
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
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
balazske added inline comments.Mar 3 2022, 2:03 AM
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
13–14

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

18–24

This has a description in the header file.

clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-posix.c
14

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
13–14

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

clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-posix.c
14

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