Those may be incompatible with C++11 and are unnecessary. We suggest
removing the template arguments when they match the types of the make_pair
arguments or replace it with std::pair and explicit template arguments when
not.
Details
- Reviewers
djasper alexfh - Commits
- rG47c4d101e009: [clang-tidy] Add a checker that removes deducible arguments from std::make_pair
rCTE213058: [clang-tidy] Add a checker that removes deducible arguments from std::make_pair
rL213058: [clang-tidy] Add a checker that removes deducible arguments from std::make_pair
Diff Detail
- Repository
- rL LLVM
Event Timeline
Looks good provided you address the comments.
clang-tidy/google/ExplicitMakePairCheck.cpp | ||
---|---|---|
41 ↗ | (On Diff #11386) | nit: I'd better not crash here even if someone defines their own ::std::make_pair. |
43 ↗ | (On Diff #11386) | nit: Missing comma after "match"? |
test/clang-tidy/google-explicit-make-pair.cpp | ||
16 ↗ | (On Diff #11386) | Please add tests with make_pair in template instantiations and in a macro. |
clang-tools-extra/trunk/test/clang-tidy/google-explicit-make-pair.cpp | ||
---|---|---|
18 | I assume the check should suggest replacements in cases where there are no dependent types, but could you add a test? And one more instantiation, so that we actually test a case where something can go wrong due to templates. |
clang-tools-extra/trunk/test/clang-tidy/google-explicit-make-pair.cpp | ||
---|---|---|
18 | We completely ignore code in template instantiations at the moment. It would be nice to check for code in templates that does not contain any dependencies on the template arguments but it's not tricky to match (or do we have an ASTMatcher for it?) |
clang-tools-extra/trunk/test/clang-tidy/google-explicit-make-pair.cpp | ||
---|---|---|
18 | Yes, we ignore code in template _instantiations_. However, template _definitions_ are handled as usual. See a test for this in test/clang-tidy/avoid-c-style-casts.cpp:78 |
I assume the check should suggest replacements in cases where there are no dependent types, but could you add a test? And one more instantiation, so that we actually test a case where something can go wrong due to templates.