<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>Also, we currently have 46 dependencies registered, and
            have a total of 164 checkers, meaning that a good percentage
            of them is affected -- would you say that a significant
            portion of these shouldn't depend on one another? If its not
            too much trouble, do you have an example on top of your head
            where you believe its appropriate, and one where its
            unnecessary?</div>
          <div><br>
          </div>
          <div>(You can always see the list of dependencies in <build
directory>/tools/clang/include/clang/StaticAnalyzer/Checkers/Checkers.inc)</div>
        </div>
      </div>
    </blockquote>
    <br>
    I mean, let's take, say, MallocChecker. It only does modeling within
    its own isolated GDM trait; it's invisible to other families of
    checkers. In this case if the model is turned off, the checker has
    no effect - it effectively gets silently disabled, we don't need an
    additional facility to get it disabled. Most of the time we also
    don't need an additional facility to make the model enabled when the
    checker is enabled - because it doesn't make much sense to disable
    the model in the first place. Such dependencies should still be
    there, just for the sake of discipline and sanity (and also for
    sorting out problems with checker names), but they aren't an
    indication that our dependency trees are actually complex enough to
    motivate a facility for dependency management.</div></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">On the contrary, the dependency between MoveChecker and
    SmartPtrModel is non-trivial: we made the latter specifically to fix
    common false positives of the former, so we recommend enabling the
    SmartPtrModel when the user wants MoveChecker. This is an example
    where things truly get complicated, and it will get even more
    complicated in the future. I think this is the actual motivation we
    have for checker dependencies and i'm very happy that it's in place.<br></div></blockquote><div> </div><div>Ah, very interesting. I actually think the contrary -- subcheckers are the ones that really drive this dependency development forward, because for them, its a feature, it it provides a safe, easy to use interface. Adding more functionalities to it could further reduce boilerplate code, improve stability and consistency.</div><div><br></div><div>On the other hand, MoveChecker's dependence and SmartPtrModel is far simpler, as they don't interact at all directly. For them, the now gone inter-checker-api header would've been sufficient as long as it gets the job done.</div></div></div>