Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/docs/ReleaseNotes.rst | ||
---|---|---|
70–85 | Please add subsections for new checks and aliases. Looks like they were removed after release branch creation. | |
clang-tools-extra/docs/clang-tidy/checks/bugprone-thread-canceltype-asynchronous.rst | ||
6 ↗ | (On Diff #323780) | Please remove unnecessary indentation and synchronize first statement with Release Notes. |
15 ↗ | (On Diff #323780) | Please fix excessive indentation. |
clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp | ||
---|---|---|
169 ↗ | (On Diff #323896) | I think this check is likely better surfaced in the concurrency module. WDYT? |
clang-tools-extra/clang-tidy/bugprone/ThreadCanceltypeAsynchronousCheck.cpp | ||
29 ↗ | (On Diff #323896) | Any particular reason to use a global variable here rather than making it a member of ThreadCanceltypeAsynchronousCheck? |
34 ↗ | (On Diff #323896) | We don't use top-level const on local value types (here and elsewhere in the patch). |
38 ↗ | (On Diff #323896) | Do we know that POSIX implementations always use a simple integer here, or do we have to worry about code like: #define PTHREAD_CANCEL_ASYNCHRONOUS (1 << 0) or #define PTHREAD_CANCEL_ASYNCHRONOUS SOME_OTHER_MACRO |
68 ↗ | (On Diff #323896) | How about: the cancel type for a pthread should not be 'PTHREAD_CANCEL_ASYNCHRONOUS'? |
clang-tools-extra/docs/clang-tidy/checks/bugprone-thread-canceltype-asynchronous.rst | ||
9 ↗ | (On Diff #323896) |
clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp | ||
---|---|---|
169 ↗ | (On Diff #323896) | It is really better in `concurrency`, I was not aware of that module (it contains only one check). |
clang-tools-extra/clang-tidy/bugprone/ThreadCanceltypeAsynchronousCheck.cpp | ||
29 ↗ | (On Diff #323896) | Member is better, I just copied the code from another file (that was added not long ago) and assumed that it is correct even if it looks not good. |
38 ↗ | (On Diff #323896) | Theoretically it is possible that the macro is defined not as a simple number (at this page see "Symbolic Constant"). But I am not sure if it is possible to get the value from the preprocessor for any constant expression. There is a similar function tryExpandAsInteger already in clang (CheckerHelpers.cpp) that can be reused here, probably it retrieves the macro definition better. The function could be put into one of the "utils" files, maybe LexerUtils.h, it is already needed at 2 places (bad-signal-to-kill-thread and here). |
clang-tools-extra/clang-tidy/bugprone/ThreadCanceltypeAsynchronousCheck.cpp | ||
---|---|---|
38 ↗ | (On Diff #323896) | Having a single place to get this information would be an improvement, but not necessary for this patch. If you don't know of a POSIX implementation that uses something other than a positive integer literal for the expansion, I think the current code is fine. |
clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp | ||
---|---|---|
114 | 80-col issue? | |
clang-tools-extra/clang-tidy/concurrency/ThreadCanceltypeAsynchronousCheck.cpp | ||
35 | Drop the top-level const unless it's a pointer/reference to a const object (here and elsewhere in the patch). | |
clang-tools-extra/docs/clang-tidy/checks/list.rst | ||
98 | It looks like this file needs to be updated from the rename. |
clang-tools-extra/clang-tidy/bugprone/ThreadCanceltypeAsynchronousCheck.cpp | ||
---|---|---|
38 ↗ | (On Diff #323896) | I found that it is good to rely on isExpandedFromMacro AST matcher instead of this whole tryExpandAsInteger function. The current solution can find only cases where the macro is defined as an integer literal. If isExpandedFromMacro is used it will work at least in all cases regardless of the value of the macro. It will not work if a variable is used to pass the value, but this does not work in the current code either. |
clang-tools-extra/clang-tidy/bugprone/ThreadCanceltypeAsynchronousCheck.cpp | ||
---|---|---|
38 ↗ | (On Diff #323896) | That's a good point! I don't think it's important to handle the case where a variable or an integer literal is used as the function call argument; we can tackle those cases if they crop up in practice and there's a need. |
- Fixed remaining formatting and rename problems.
- Removed tryExpandAsInteger, use matcher instead.
- Improved test.
Before landing this, can you update the title of this to reflect its in the concurrency module, the title is typically used for the commit message.
80-col issue?