Detects incorrect usages of std::enable_if that don't name the
nested 'type' type.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clang-tidy/bugprone/IncorrectEnableIfCheck.cpp | ||
---|---|---|
57 | Result got source manager.... | |
61–62 | do we still need typename in C++20 in this context ? | |
67 | since C++14 we should recommend using enable_if_t | |
clang-tools-extra/docs/ReleaseNotes.rst | ||
129 | ||
clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.rst | ||
21 | shoudnlt be enable_if ? | |
34 | this is valid usage, uses enable_if_t | |
37 | this may not compile, anyway, what if "type" got "type" ?:P | |
44 | should be suffucient | |
47 | maybe "Consider" |
clang-tools-extra/clang-tidy/bugprone/IncorrectEnableIfCheck.cpp | ||
---|---|---|
67 | I didn't add replacement logic for C++14 or C++20 since there are separate tools for those, and though it'd be cleaner to have independent set of tools (e.g., first run bugprone-incorrect-enable-if, then run modernize-type-traits). |
Do you have plans to also detect the bugprone scenario described in the Notes here?
https://en.cppreference.com/w/cpp/types/enable_if
No need to have it in this patch, but would be good to keep it in mind if we want to add it in the future (preferably) or create a separate check.
clang-tools-extra/docs/clang-tidy/checks/bugprone/incorrect-enable-if.rst | ||
---|---|---|
6 | Please synchronize with statement in Release Notes after Piotr's comment addressed. |
clang-tools-extra/clang-tidy/bugprone/IncorrectEnableIfCheck.cpp | ||
---|---|---|
61–62 | Oh, I did not know that. Thanks! |
> Do you have plans to also detect the bugprone scenario described in the Notes here?
I didn't have plans in this review, or in the immediate future after. I did name this check broadly as "bugprone-incorrect-enable-if," so I imagine this other scenario could go into this new check.
clang-format not found in user’s local PATH; not linting file.