Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-52579

libdeps graph linter: Missing LIBDEPS Edges

    • Type: Icon: New Feature New Feature
    • Resolution: Won't Do
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Server Development Platform

      Implement the graph linter employing the command line tool, graph collection service and graph visualization tool where applicable. Description from the technical design doc:

      If the graph links, can any LIBDEPS edges actually be missing? In one sense, the answer is no. The fact that all nodes in the dependency graph link is fairly compelling evidence that every link target has at least the required libraries on its link line.

       

      However, the situation may be more fragile than it appears. If link target A makes direct use of symbols from library Z but does not declare its own dependency on Z, it must be linking successfully because one or more of A’s other dependencies has transitively promulgated Z to A’s link line by itself declaring a public dependency on Z. If those Z exporting dependencies were to later reduce Z from a public to a private library dependency, A would no longer see Z on its link line and would suddenly fail to link.

       

      Therefore, A should be flagged as having a missing dependency on Z if:

       

      • A uses (has undefined references to) symbols exported from library Z.
      • A does not directly declare a dependency on library Z.
      • Z should in fact be a private dependency in all exporters of Z reachable from A.

       

      This is a fairly stringent set of requirements, but it is not impossible. Especially if we intend to start moving more libraries to private (an explicit goal of the linter) this situation is likely to become increasingly relevant.

       

      Another situation where A could be flagged as having a missing library dependency on Z would be if A did not declare a public dependency on Z, but use of the interface to library A by a client node C ought to induce C to have a dependency edge on Z because use of A results in unresolved symbols provided by Z. Again, C might link in practice because C achieves, either directly or transitively, a dependency on Z via its other dependencies. Again, this is fragile because if C’s dependencies change such that they cease to transitively export Z to C, C will suddenly fail to link. If Library A induces a Z dependency on users of its interface but does not declare any dependency on Z, then Z should be flagged as missing (and as needing to be public) from A.

       

      There may be other cases like the above, these are intended to be illustrative not exhaustive. Overall, adding libdeps flagged as missing is a relatively safe operation. Adding edges to the graph that are already being satisfied through back channels is unlikely to break things. 

       

      Finally, note that the mechanics of detecting this class of errors overlaps heavily with that of identifying public nodes that should be private and vice versa. This check should be implemented after those checks are implemented.

            Assignee:
            backlog-server-devplatform [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
            Reporter:
            daniel.moody@mongodb.com Daniel Moody
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: