[PATCH] D91000: [clang-tidy] Add bugprone-unsafe-functions checker.
Fütő Gergely via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Sat Dec 31 07:46:30 PST 2022
futogergely added a comment.
In D91000#3862210 <https://reviews.llvm.org/D91000#3862210>, @whisperity wrote:
> In D91000#3861942 <https://reviews.llvm.org/D91000#3861942>, @aaron.ballman wrote:
>
>> My concern with that approach was that we pay the full expense of doing the matches only get get into the `check()` function to bail out on all the Annex K functions, but now that there are replacements outside of Annex K, I don't see a way around paying that expense, so I think my concern has been addressed as well as it could have been.
>
> I think that Clang-Tidy checks are instantiated per AST. I will look into whether we can somehow do the disabling of the check as early as possible! (In that case, we could simply NOT register the matcher related to Annex-K functions.) Either way, I'll do a rebase, re-run the tests and etc., and likely take over the check.
I checked, and I think that at the point of ClangTidyCheck::registerMatchers the preprocessor has not been executed yet... (and we need the value of macros __STDC_LIB_EXT1__ and __STDC_WANT_LIB_EXT1__ to decide if we need to register some matchers or not) @whisperity could you maybe double-check it please?
What we could do is:
1. add a new checker option to decide if we suggest replacements from AnnexK. We could avoid registering matchers this way, but I don't really like this, having an option for something we could decide from the defined macros.
2. As a TODO, we could make possible to register checkers AFTER the preprocessor is executed. I have not looked into this, so I don't really know if it is possible at all in the current architecture.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D91000/new/
https://reviews.llvm.org/D91000
More information about the cfe-commits
mailing list