On Feb 22, 2012, at 9:36 AM, Anna Zaks <[email protected]> wrote: >> (I see that someone on Radar thought the answer was "yes", but...) >> >> Also, separately...is this the way we're going to do inter-checker >> dependencies? I like how simple it is! And since all the checker >> registration is done with vectors, it even handles ordering. > > I don't think this handles ordering.. The ordering still depends on the order > in which the checkers are defined in the Checker.td file. That's something > which needs to be fixed. > >> But I don't know how it will scale, and it does sort of compel us to expose >> a registration function for /every/ checker. (Just like warning flags, if we >> decide it's okay not to have a registration function for some checker, we'll >> end up in a situation where we need it.) >> > > We do not have the dependency mechanism set in stone. We can revisit this > later on. I view this approach as something that we can use to define > dependencies in special cases. Currently, this is the only dependency we > have, though it might quickly change..
Jordy, To add what Anna said, this solution is what we can work with, and it allows us to explore the kind of behavioral dependencies we would want between checkers. Doing it this way has serious limitations; for example, if one explicitly disables a checker from the command line, how does it interplay with such dependencies? What we have is progress towards figuring out what kind of behavioral patterns we need to support as part of expressing checker dependencies, and what that means for the end user. Ted
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
