Remove the explicit unlock function and rely on the drop handler always. The only semantic difference is the order in which the locks are unlocked, but this should not be an issue (from a deadlock perspective), because the order in which they are locked is the always the same.
Motivated by how easy (especially when using the ?/try syntax) it is to accidentally skip the explicit calls to PackageLock::unlock. The reason why this still works is that the guards that it contains automatically unlock when they are dropped, so PackageLock's drop handler should do the right thing, without need for an explicit unlock call.
Remove the explicit unlock function and rely on the drop handler always. The only semantic difference is the order in which the locks are unlocked, but this should not be an issue (from a deadlock perspective), because the order in which they are locked is the always the same.
Motivated by how easy (especially when using the
?/try syntax) it is to accidentally skip the explicit calls toPackageLock::unlock. The reason why this still works is that the guards that it contains automatically unlock when they are dropped, soPackageLock's drop handler should do the right thing, without need for an explicitunlockcall.Test Plan
Stack
741
745
753
754
759
760
854
855
856
857
858
859
860
See also: #790 for main.