Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Merged
merged 1 commit into from
Jan 5, 2024
Merged

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

merged 1 commit into from
Jan 5, 2024

Commits on Jan 4, 2024

  1. Let module extensions track calls to Label() 

    ... 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 bazelbuild#20721.

Closes bazelbuild#20742.

PiperOrigin-RevId: 595818144
Change-Id: Id660b7a659a7f2e4dde19c16784c2ab18a9ceb69
    @Wyverald @iancha1992
    Wyverald authored and iancha1992 committed Jan 4, 2024
    Configuration menu
    Copy the full SHA
    bbeb87e View commit details
    Browse the repository at this point in the history