tree 17d2a1cfb7808629d6fd87213b0a41a82c6a2bc2
parent 99dcdb007ee7a9a47df57744439e5e7a1fcaa923
author Ian (Hee) Cha <heec@google.com> 1704414066 -0800
committer GitHub <noreply@github.com> 1704414066 +0000
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJll0tyCRBK7hj4Ov3rIwAApVgIAJFv8bTR7FJcl4yXJmJow+Ic
 0HwSZG/wikPsmqkxUhlXBLfDdjiOgEAIqHq59BzH8JghUqPy9dn/cPOc0kSK5U5o
 d3ECNughPUZ7TqsqWjECBgEz1hFMRRbmzE19eJ9HOqhIkc7iFfJTu++DOrBdZeYg
 idDbv/8+bRM6cdRrObgtkhI/4qF+GP7OGlacDEkiX4eiHMzPqcF1L3UYnCWCCoh1
 FAEp6HvsO26hugE4Zjjc5ZO3FbPdzf+pkRjXlFl2J0zDKalsBmExTW3IMHymqVlW
 XBCyJky31IxPtv0KdyueGnuLlf0oRqiqUQ+WBQ5yV7dfWo4yc+xGlawg1TteKYs=
 =vONK
 -----END PGP SIGNATURE-----
 

[7.0.1] Let module extensions track calls to `Label()` (#20750)

... that use repo mapping. This is a rather obscure case of the lockfile
being stale; if the `Label()` constructor is called in an extension impl
function, and that call uses repo mapping of any form (i.e. the argument
looks like `@foo//bar`), then we need to be ready to rerun the extension
if `@foo` were to suddenly map to something else.

I also did a minor refactoring in `SingleExtensionEvalFunction` around
the logic to decide whether the locked extension is up-to-date. Right
now we perform a "diff" between the locked extension and what we expect
to be up-to-date, and if a "diff" is found *and*
`--lockfile_mode=error`, we basically perform a diff again. We also
don't short circuit; that is, if the transitive bzl digest has changed,
there's no point in seeing whether any files have changed, but we do
right now.

A follow-up will be sent to fix the analogous bug for repo rules.

Fixes #20721.

Closes #20742.

PiperOrigin-RevId: 595818144
Change-Id: Id660b7a659a7f2e4dde19c16784c2ab18a9ceb69

Co-authored-by: Xdng Yng <wyverald@gmail.com>