On Nov 4, 2010, at 8:44 PM, Jim Goodnow II wrote:
>> In other words, if the checker is Objective-C specific, it should only be
>> enabled if the code is Objective-C or Objective-C++, but that doesn't solve
>> the problems we're encountering with migrating the checkers and the rest of
>> the analysis engine to work with C++.
>
> So, there is a place for some discrimination between checkers based on
> language variant. I was also thinking in terms of efficiency. As more
> checkers are written for C++ specific analysis, having them run on C or
> ObjectiveC is just burning cycles needlessly. A checker that is more
> universal can be registered with multiple language variants.
I should also add that Checkers have the ability to make some some of this
determination in their registration methods. For example:
void clang::RegisterObjCAtSyncChecker(GRExprEngine &Eng) {
// @synchronized is an Objective-C 2 feature.
if (Eng.getContext().getLangOptions().ObjC2)
Eng.registerCheck(new ObjCAtSyncChecker());
}
The LangOptions object encapsulates a bunch of flags that indicate what
language features are currently active for the translation unit, including
whether or not C++ support is enabled.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
