[SERVER-52582] libdeps graph linter: private that should be public Created: 03/Nov/20  Updated: 17/Oct/23  Resolved: 17/Oct/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Daniel Moody Assignee: [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-52578 integrate libabigail data into libdep... Closed
Assigned Teams:
Server Development Platform
Participants:

 Description   

from the document:

This is actually one of the simpler ones. If A declares a private dependency on Z, but use of A’s interface by a client C induces a dependency on symbols from Z, then A’s declaration of the Z dependency should be promoted from private to public. Such a transformation is always safe: no edges are removed, and no other nodes will have their current dependency set reduced.

 

There is a subtle angle to this one (of course!): it is possible that use of A’s interface induces symbol dependencies on Z in C not because of the direct use of Z in A’s interface, but because A induces the use of symbols from B, and use of those symbols from B induces the use of symbols from Z. If all of the induced uses of Z in consumers of the A interface can be explained away by other should-be-public dependencies of A (like B), then it makes no difference if Z is public or private in A: B will need to be public in A, and Z will need to be public in B. In such situations, it seems best that if A really does make direct use of Z internally, that it be declared a private library dependency despite the fact that B will drive it through A as public to A’s clients. Otherwise, if B later changed such that it no longer induced a Z dependency on clients of A’s interface, Z would suddenly become flagged as public-should-be-private in A.

 

Given that the transformation suggested by the linter is safe and the conditions reasonably easy to understand, it is probably a good candidate for implementation early in the project.


Generated at Thu Feb 08 05:28:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.