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 Authored by aaronpuchert on Sep 17 2018, 5:27 PM. 
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?