[PATCH] D22208: [clang-tidy] Fixes to modernize-use-emplace

Piotr Padlewski via cfe-commits cfe-commits at lists.llvm.org
Tue Aug 2 11:13:41 PDT 2016


Prazek marked 5 inline comments as done.

================
Comment at: clang-tidy/modernize/UseEmplaceCheck.cpp:115
@@ -95,1 +114,3 @@
+  auto CtorCallSourceRange = CharSourceRange::getTokenRange(
+      InnerCtorCall->getExprLoc(), CallParensRange.getBegin());
 
----------------
alexfh wrote:
> Prazek wrote:
> > alexfh wrote:
> > > Prazek wrote:
> > > > alexfh wrote:
> > > > > This doesn't seem to be an issue, since expression `v.push_back(obj.member())` won't trigger this check: it expects that the argument of the `push_back` call is a `cxxConstructExpr` or a `cxxFunctionalCastExpr`.
> > > > what about the implicit conversion? What if obj.member would return object that is different from the one that v stores, but it is convertible to it?
> > > Sounds almost like a recipe for a test case ;) Have you tried to construct it this way?
> > Yes, I think I emulated this case in line 190. I tried to hit this problem but could not find the test case.
> >> if The Call->getArg(0) will be a memberExpr (call to member function)
> > what about the implicit conversion?
> 
> I think, I know what happens in this case. When an implicit conversion happens in `v.push_back(obj.member())`, then `Call->getArg(0)` is an implicit `CXXConstructExpr`, not a `MemberExpr` (`MemberExpr` will be its indirect child). The case should be handled correctly.
That might be it. I remember that in some early version I was biding to MemberExpr somewhere, which might cause it.


https://reviews.llvm.org/D22208





More information about the cfe-commits mailing list