george.karpenkov added a comment. > Deal with the consequences of this, and just correct all plist files to now > refer to the new base checker.
What does it mean? > Each time a report is emitted from these checkers, create a ProgramPointTag, > and "manually" make sure the emitted checker name doesn't change. I'm not sure what do you propose exactly, but sounds pretty bad. > Rename osx.cocoa.RetainCount to something else. This one is clearly > nonsensical, but let's put it here for the sake of completeness. I don't think we can rename the old checker, as older Xcode versions have "osx.cocoa.RetainCount" hardcoded in them. TBH I'm not really sold on the way we "bundle" multiple checkers (from the tablegen) into a single class. For one, that means options don't work at all, and essentially the checker name is defined by the class which was registered by the tablegen first (which should not even be visible, and should be an internal implementation detail). Do you have better proposals on how, conceptually, grouped checkers should be organized? Essentially, we have a single checker class with two checks, which should be toggle-able orthogonally from each other. For legacy reasons, we can't quite get rid of `osx.cocoa.RetainCount` (but even if we could, what then?) Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D55400/new/ https://reviews.llvm.org/D55400 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
