New patch! In this version: * no longer uses FoldingSetNodeID, which hopefully addressed performance concerns (this means "s->a_ = s->a_" is no longer caught, but that has never happened to me anyway) * ObjC support as requested by Jordan * Fix to an existing ObjC test that triggered this warning (accidentally I think)
On Mon, Jun 25, 2012 at 5:10 PM, Jordan Rose <[email protected]> wrote: > > On Jun 25, 2012, at 16:27 , Nico Weber <[email protected]> wrote: > > On Mon, Jun 25, 2012 at 3:49 PM, Jordan Rose <[email protected]> > wrote: > > > On Jun 25, 2012, at 14:43 , Nico Weber <[email protected]> wrote: > > Full build of the 'chrome' target with this warning on my MBP: real > 31m41.500s > Same clang binary at the same revision, without the warning: real > 31m53.572s > > So the compile-time impact of the warning is below noise I'd say. > > Nico > > > Did you remember to add a guard around the "work" part of > CheckIdentityMemvarAssignment? Or were you still doing the work and just > not emitting the warning? > > > I uncommented the call to "CheckIdentityMemvarAssignment" (and clang > warned me that the static function CheckIdentityMemvarAssignment > wasn't used). With "same binary" I meant "built at the same revision" > > > Okay, I see. I'm a little concerned along with Ted because copying over > pieces of another struct does seem like something common enough to do, but > I guess it's fine. > > This probably won't catch "this->_a = _a", but maybe that's okay. It is a > typo you might make in a setter, though. > > BTW, this would be a good warning to have in Objective-C as well ( > ObjCIvarRefExpr). The equivalent example there would be "self->_a = _a". > > Thanks for working on this. I think over all it is a good warning to have. > > Jordan >
clang-memvar-assign.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
