tree 7960c81d86a6f6c3be90a32671bf7fd34e51f4f2
parent 0725711d76f8738be0f57cf210efaea0e0a32742
author bazel.build machine account <15028808+bazel-io@users.noreply.github.com> 1701377501 -0500
committer GitHub <noreply@github.com> 1701377501 +0000
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJlaPXdCRBK7hj4Ov3rIwAA8dsIAFOiOktUuTrwlHKnGrOgcqOY
 4IWDebou98CkCWSoth75bNMdQ5qU4ET9bnQd9bvZUEpAY843MuI/SE76L4438+eT
 LzjyLMonAqOgwBzjzkMaqOB006aIJnUXiJGvAEZYyn8FY9vH0zY70y53QlfhCqtn
 uUDyeJWHqcGsZEFoy6T3Pe5Gce9FWSEYNZbQUnbtPu/nmF3GfNBS4lqO+tR/9p8z
 AfASuCLco7oW7PBGshQ5sTDlJu+NnRZAemHfbclkNvTI+cq5Fo9GHHSE3/3SahhA
 p1cV+9Cx9QRvOzAWeR6LjErBdR1V07a4WT03z6EqN6bLWTI268I/dCLuMrP1aJM=
 =K1k0
 -----END PGP SIGNATURE-----
 

[7.0.0] Make lockfile extension updates more obviously correct (#20400)

* Removes code paths in `BazelLockFileModule` that are never taken now
that lockfile update events are replayed by Skyframe.
* `BazelModuleResolutionEvent` no longer contains a `BazelLockFileValue`
that is internally inconsistent: Previously, this values combined the
(potentially updated) extension usages resulting from the resolution
with the old locked extension results obtained from the previous state
of the lockfile. The logic in `BazelLockFileModule` handled this
correctly, but it should now be more obvious that it does so.
* No longer parse the lockfile twice, once in `BazelLockFileFunction`
and once in `BazelLockFileModule`.

Closes #20311.

Commit
https://github.com/bazelbuild/bazel/commit/1691f60c2ec222a392c8708ddc4cc35a969c4f7c

PiperOrigin-RevId: 586744057
Change-Id: Id85dbde627878c18baf3c375a0091a4f989b146b

Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>