This imitates the code for MemberExpr. I hope it is right, for I have
absolutely no understanding of ObjC++.
Fixes 38896.
Differential D52200
Thread safety analysis: Handle ObjCIvarRefExpr in SExprBuilder::translate aaronpuchert on Sep 17 2018, 5:27 PM. Authored by
Details
This imitates the code for MemberExpr. I hope it is right, for I have Fixes 38896.
Diff Detail
Event TimelineComment Actions Adding a reviewer who knows more about ObjC than I do.
Comment Actions Thanks to both of you for the reviews. I'll see what I can do about the arrows. My gut feeling is that using {Member,ObjCIVarRef}Expr::isArrow is the right way, but it's not yet obvious to me how.
Comment Actions I found something that would theoretically work: P->setArrow((isa<CXXThisExpr>(ME->getBase()) && Ctx && Ctx->SelfArg) ? Ctx->SelfArrow : ME->isArrow()); So if we have this and a context that tells us we have to replace this by something else, then we check Ctx->SelfArrow, otherwise we take ME->isArrow(). But that doesn't work. When translating into the TIL (typed intermediate language), referencing and dereferencing operators are completely ignored. struct Foo { Mutex mu_; void foo1(Foo *f_declared) EXCLUSIVE_LOCKS_REQUIRED(f_declared->mu_); }; void test() { Foo myfoo; myfoo.foo1(&myfoo); // \ // expected-warning {{calling function 'foo1' requires holding mutex 'myfoo.mu_' exclusively}} } With the above change we warn that calling function 'foo1' requires holding mutex 'myfoo->mu_' exclusively. It should be (&myfoo)->mu_, but the & is lost. So we can't derive the information that we want from isArrow alone. Now there is a reason why these operators are ignored — the TIL tries to "canonicalize" expressions, so that it detects that (&myfoo)->mu_ and myfoo.mu_ are the same thing. Changing that is probably possible, but beyond the scope of this change. Short of that, we must be able to detect pointers. I think we could use Type::isAnyPointerType instead of Type::isPointerType in hasCppPointerType (and probably rename that). For later I think we should consider a different canonicalization that doesn't just ignore & and *. Comment Actions Hmm. It would be consistent to apply the same rule to both cases, and I don't have any serious concerns about dropping it. If anything, Objective-C pushes the ivar-decorating convention harder than C++ does, since it's officially blessed in the language.
Comment Actions It seems that self is an ordinary DeclRefExpr unlike this, which is a CXXThisExpr. Which means we'd have to make it dependent on the name whether we drop it, but self in C/C++ is just an ordinary variable. So I think I'll leave the self-> part for now. It certainly doesn't hurt. |
ME is kind of a poor name; can you switch to IVRE like you used in the implementation?