Skip to content
Snippets Groups Projects
Select Git revision
0 result
Search by author
  • Any Author
0 authors
This project is mirrored from https://github.com/bazelbuild/bazel.git. Pull mirroring updated .
  1. Feb 12, 2025
  3. Feb 11, 2025
  5. Feb 10, 2025
  7. Feb 07, 2025
  9. Feb 06, 2025
  11. Feb 05, 2025
  13. Feb 04, 2025
  15. Feb 03, 2025
  17. Feb 01, 2025
    • Fabian Meumertzheim's avatar
      [8.1.0] Add `--incompatible_enforce_starlark_utf8` (#25152) · 549e13e1
      Fabian Meumertzheim authored 
      If enabled (or set to `error`), fail if Starlark files are not UTF-8
encoded. If set to `warning` (the default), emits a warning instead.

Bazel already assumes that Starlark files are UTF-8 encoded for e.g.
filenames in actions executed remotely. This flag doesn't affect this,
it only makes encoding failures more visible.

Work towards #374

Closes #24944.

PiperOrigin-RevId: 721513249
Change-Id: I1d3363168c6cd5d37abf96e0401e34866b6679d7

(cherry picked from commit e7934ce9)

Fixes #25148
      549e13e1
  19. Jan 31, 2025
  21. Jan 30, 2025
    • bazel.build machine account's avatar
      [8.1.0] See and use more than 64 CPUs on Windows (#25140) · 12a3fc00
      bazel.build machine account authored 
      Fixes #24827

Closes #25087.

PiperOrigin-RevId: 721285704
Change-Id: Id5c1a8b699f7c5bca1995dba7a8c871805b1a598

Commit
https://github.com/bazelbuild/bazel/commit/f64f3605226e380d322f8cf503b014c05747f990



Co-authored-by: default avatarFabian Meumertzheim <fabian@meumertzhe.im>
      12a3fc00
    • Ian (Hee) Cha's avatar
      [8.1.0] Emit spawn runner with `--subcommands` (#25051) · 04076976
      Ian (Hee) Cha authored 
      This makes it easier to tell whether a given spawn ran remotely or
sandboxed, which is especially important for test actions (which run
multiple spawns).

Closes #24987.

PiperOrigin-RevId: 718862807
Change-Id: Ib88102c06d4641fed717b809eaee4e9485853452

Commit
https://github.com/bazelbuild/bazel/commit/60fb7a4733d7d7582b77600396c3e50d686cf36f



Co-authored-by: default avatarFabian Meumertzheim <fabian@meumertzhe.im>
      04076976
    • Alexandre Rostovtsev's avatar
      [8.1.0] Respect comprehension variable shadowing in Starlark debugger output (#25139) · 11e85a4d
      Alexandre Rostovtsev authored 
      The Starlark interpreter, for optimization reasons, stores the bindings
of comprehension variables in their enclosing function's locals array.
This means we cannot naively transform the locals array into a name ->
value map for debugger output: there may be multiple initialized
variables having the same name.

And since we have been building this map using buildOrThrow(),
attempting to debug a function with a comprehension variable having the
same name as a parameter or other local variable would crash Bazel.

The immediate fix would be to track comprehension bindings' lexical
scope (by saving a pointer to the comprehension AST node; note that a
comprehension's scope has a non-trivial shape - it has a "hole" punched
out for the first `for` clause), so we can ignore comprehension
variables outside their comprehension, and emit only the innermost one
when inside a comprehension (relying on the fact that the resolver
places inner comprehensions' variable bindings after the outer ones).

However, while this fixes the crash and the most obvious correctness
problem, it does not allow the user of the debugger to examine the value
of the shadowed variables.

The proper fix - to be implemented later - would be to push a new
debugger frame when debugging inside a comprehension.

See https://github.com/bazelbuild/bazel/issues/24931 and discussion with
@fmeum in https://github.com/bazelbuild/bazel/pull/24919

PiperOrigin-RevId: 715908968
Change-Id: I3066e89f2e92d0fd0e483851a767b7c7d70ab555

Cherry pick of

https://github.com/bazelbuild/bazel/commit/29bdfa392bf8a551d0fad5cee4e425e042194bf0
      11e85a4d
    • bazel.build machine account's avatar
      [8.1.0] Include --run_env in --script_path (#25133) · 28c5500b
      bazel.build machine account authored 
      Previously this only applied if you did `bazel run` without
`--script_path`.

Closes #25060.

PiperOrigin-RevId: 720874776
Change-Id: Ib118fe970cac94e87ace9ac870b2b70d7b65bbc0

Commit
https://github.com/bazelbuild/bazel/commit/b3a04919a2112460afe7485e71bc343d3b7bdd1c



Co-authored-by: default avatarKeith Smiley <keithbsmiley@gmail.com>
      28c5500b
    • bazel.build machine account's avatar
      [8.1.0] Improve incompatible platform skipping + config_setting + label_flag … (#25137) · b5c62f7c
      bazel.build machine account authored 
      …behavior.

Context: https://github.com/bazelbuild/bazel/issues/23003

Technical notes:

This involves a lot of subtle interactions between the concepts of
platform skipping, `config_setting`, `label_flag`, and aliases.

This fixes the problem where a `config_setting` keyed on a `label_flag`
that references an incompatible target gave the error "not a valid key
for the `config_setting"`. The reason is that `config_setting` expects
all `flag_values` keys to expose `BuildSettingProvider`. But an
incompatible target (whether directly or because one of its deps is
incompatible) is a `RuleConfiguredTarget` that only exposes
`IncompatiblePlatformProvider`.

I fixed this by exempting `label_flag` from being marked incompatible
due to incompatible deps. It therefore returns its normal value, which
is a specially created `AliasConfiguredTarget` that adds the right
`BuildSettingProvider` via `AliasConfiguredTarget.overrides`.

All well and good. But if you build such a `label_flag directly`, Bazel
still returns an error that it's incompatible due to incompatible deps.
That's great, and accurate. But why does it do that if we exempted it
from being incompatible in that situation?

The reason is that, as an `AliasConfiguredTarget`, it forwards its
dependencies' provider. Since its dependency has
`IncompatiblePlatformProvider`, that gets forwarded implicitly, so the
routine "is the top-level target incompatible?" check still triggers on
the `label_flag` the build requested.

That's a bit odd: the `label_flag` both is and isn't indirectly
incompatible depending on which logic is checking. But there's no easy
way around this: `ConfigSetting` *has* to consider it compatible to
avoid it being a special `RuleConfiguredTarget` with
`IncompatiblePlatformProvider`. But since i's normal form is an alias
that auto-triggers the "forward my incompatible deps" logic

Point is this is all a bit subtle. I vetted reasonable behavior as best
I can, but I'm not 100% confident we capture every corner case correctly
or intuitively. There's just too much subtle interplay between various
delicate parts of the build API.

You could just as well argue, for example, that `$ bazel build
//my:label_flag` should *never* produce an incompatibility error since
label flags are dependency aliases, and not meant to build anything
directly. If you wanted that behavior just use a plain `alias`. But I
don't want to scope-creep this fix so I'll just note these API
ambiguities and leave this PR's ambition as-is.

Relatedly you'll see I updated a few pieces of "foo was skipped"
reporting messages to reflect that `label_flag` is an alias. Note that
change *cannot* kick in for requested builds incompatible `alias`
targets. Those are properly considered incompatible, which means they
get replaced with `RuleConfiguredTarget` with an
`IncompatiblePlatformProvider`. So those essentially cease to be aliases
for top-level "foo was skipped"-style reporting.

See the test methods I added for specific expectations I encoded.

We should also update the `config_setting` documentation on `label_flag`
and `alias` interaction.

Fixes https://github.com/bazelbuild/bazel/issues/23003.

PiperOrigin-RevId: 702118583
Change-Id: Ia6e80af57cc3b4e6d2574bf28a1d8fe0dbff0852

Closes #24542.

Change-Id: Ia6e80af57cc3b4e6d2574bf28a1d8fe0dbff0852
PiperOrigin-RevId: 702478496

Commit
https://github.com/bazelbuild/bazel/commit/916e8581bb2861838fbec0cb6e9228caac7efddc



Co-authored-by: default avatarGoogler <gregce@google.com>
      b5c62f7c
    • bazel.build machine account's avatar
      [8.1.0] Forward `exec_properties` to main test spawn's execution info (#25138) · ad2d5685
      bazel.build machine account authored 
      This makes `exec_properties` such as `no-remote-exec` effective for the
main test spawn, where they previously only affected post-processing
spawns such as test XML generation.

Pros:
* relatively simple (and more precise than `tags`) way to affect test
execution using existing API
* provides consistency between test spawns
* provides consistency between test spawns and spawns produced by
Starlark actions

Cons:
* similar to Starlark actions, execution info is "polluted" with
`exec_properties` such as `OSFamily` and `container-image`, which shows
up in `aquery` and may increase memory usage
* the fact that `exec_properties` end up in execution info appears to
have been an unintentional side effect of
https://github.com/bazelbuild/bazel/commit/adb56ccd811b60db5dc05c5434cd7c436a6cb81b
rather than a conscious design decision
* provides functionality may be better addressed by [Execution Platform
Scoped Spawn
Strategies](https://github.com/bazelbuild/proposals/blob/main/designs/2023-06-04-exec-platform-scoped-spawn-strategies.md)

Closes #24979.

PiperOrigin-RevId: 721088264
Change-Id: I7ce5c899ed6a647831f156f6b34c1f776655425c

Commit
https://github.com/bazelbuild/bazel/commit/357b091dc7afa9f40c78acca0c53e63ea0b20c8b



Co-authored-by: default avatarFabian Meumertzheim <fabian@meumertzhe.im>
      ad2d5685
    • Tiago Quelhas's avatar
      [8.1.0] Garbage collect install bases older than 30 days by default. (#25127) · ac5ce380
      Tiago Quelhas authored 
      PiperOrigin-RevId: 720535693
Change-Id: I2467ab2d2426b44382904d50b58edc7602ee457e
      ac5ce380
    • Chi Wang's avatar
      [8.1.0] Do not invalidate remote metadata during action dirtiness check (#25126) · 312aa750
      Chi Wang authored 
      ... if the corresponding output is materialized afterwards and hasn't
been changed.

Failing to do so will cause an incremental build to re-check the action
cache for actions whose outputs were materialized during last build.
This can be very slow if the size of the outputs are large.

We achieved this by storing `FileContentsProxy` in the remote metadata
after materialization. During dirtiness check, we compare remote
metadata and the corresponding local metadata with their `digest`, or
`proxy` if `digest` is not available for local metadata,

A user reported back the wall time of their very first increment build
is improved by this change from `14s` to less than `1s` in common case,
and from `115s` to less than `1s` in worst case.
https://github.com/bazelbuild/bazel/issues/24763

PiperOrigin-RevId: 715734718
Change-Id: Id1a1a59d8b5f3e91a7ae05a73663ff37eee6d163

Fixes #24940.
      312aa750
  23. Jan 29, 2025
  25. Jan 28, 2025