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 06, 2024
  3. Feb 03, 2024
  5. Feb 02, 2024
  7. Feb 01, 2024
  9. Jan 31, 2024
    • Tiago Quelhas's avatar
      [7.1.0] Make some minor adjustments to the compact execution log format and... · fbd9bcb2
      Tiago Quelhas authored 
      [7.1.0] Make some minor adjustments to the compact execution log format and document it better. (#21146)

* Remove the Output top-level payload type. It can only appear as a
sub-message of a Spawn.
* Add an Invocation top-level payload type. It is currently empty but
reserved for anticipated needs (e.g. to report the digest function
used).
* Spell out some guarantees (and non-guarantees) about the format.

Renumbering is fine, since the format hasn't made it into a release yet.

PiperOrigin-RevId: 602352295
Change-Id: I6044c9a9a51360dfce5701071883b318b1e9a5c2
      fbd9bcb2
    • bazel.build machine account's avatar
      [7.1.0] Add bash completion for external targets (#21149) · a6d410a2
      bazel.build machine account authored 
      Completion for both repository names and targets in (fetched) external
repositories is provided based on `bazel mod dump_repo_mapping`.

RELNOTES: Bazel's Bash completion can now complete external repository
labels when using `--enable_bzlmod`.

Closes #20693.

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



PiperOrigin-RevId: 602923007
Change-Id: I7c7dfe3d90a2921f473c2d2fedbc054da67932ac

Co-authored-by: default avatarFabian Meumertzheim <fabian@meumertzhe.im>
      a6d410a2
    • Tiago Quelhas's avatar
      [7.1.0] Harmonize BUILD files. (#21145) · 9758e13a
      Tiago Quelhas authored 
      PiperOrigin-RevId: 601430837
Change-Id: Ie7739e2e4aead81a8a3ab7d9eedf47294ed9f855
      9758e13a
    • bazel.build machine account's avatar
      [7.1.0] Starlark: reuse positional array in native calls where possible (#21144) · 5aa69ed0
      bazel.build machine account authored 
      This is a resubmission of @stepancheg's #12782, which became stale, with
this original description:

====

For certain calls like `type(x)` or `str(x)` or `l.append(x)` we can
reuse `positional` array argument of `fastcall` to pass it to the
`MethodDescriptor.call` and skip all runtime checks in
`BuiltinFunction`.

This optimization cannot be applied if
* a function has extra positional or named arguments
* has arguments guarded by flag
* accepts extra `StarlarkThread` parameter
* has unfilled arguments with default values

So this optimation won't be used for calls `list(x)` or `bool()`.

For `type(1)` called in loop, the result is 15% speedup:

```
A: n=30 mean=5.705 std=0.387 se=0.071 min=5.131 med=5.827
B: n=30 mean=4.860 std=0.345 se=0.064 min=4.396 med=4.946
B/A: 0.852 0.820..0.884 (95% conf)
```

For `bool()` (no argument) called in loop, it results in 1% slowdown:

```
A: n=29 mean=9.045 std=0.603 se=0.113 min=8.096 med=9.400
B: n=29 mean=9.134 std=0.520 se=0.098 min=8.248 med=9.448
B/A: 1.010 0.976..1.045 (95% conf)
```

====

Beyond the original PR, this includes benchmarks, a test case addressing
a review comment and small adaptions to the implementation to make it
work with recent changes.

Benchmark results with JDK 21 and `--seconds 5`:

```
before:
File src/test/java/net/starlark/java/eval/testdata/bench_call.star:
benchmark                        ops     cpu/op    wall/op   steps/op   alloc/op
bench_call_bool             67108863      100ns      100ns          3        87B
bench_call_dict_get         33554431      159ns      158ns          5       143B
bench_call_dict_get_none    33554431      180ns      179ns          6       143B
bench_call_list_append      33554431      170ns      169ns          5       207B
bench_call_type             67108863      139ns      138ns          4       111B

after:
File src/test/java/net/starlark/java/eval/testdata/bench_call.star:
benchmark                        ops     cpu/op    wall/op   steps/op   alloc/op
bench_call_bool             67108863      100ns      100ns          3        87B
bench_call_dict_get         33554431      155ns      154ns          5       143B
bench_call_dict_get_none    33554431      174ns      174ns          6       143B
bench_call_list_append      67108863      141ns      141ns          5       183B
bench_call_type             67108863      115ns      114ns          4        87B
```

Closes #19708.

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



PiperOrigin-RevId: 602821608
Change-Id: If40e2eb1e09ec43d56b36ba13987aa5312fd47ec

Co-authored-by: default avatarFabian Meumertzheim <fabian@meumertzhe.im>
      5aa69ed0
    • Tiago Quelhas's avatar
      [7.1.0] Avoid using `InputStream.available()` to detect EOF while reading... · 36e65215
      Tiago Quelhas authored 
      [7.1.0] Avoid using `InputStream.available()` to detect EOF while reading delimited protos. (#21143)

It's not a reliable method to check for EOF: it returns how many bytes
are guaranteed to be read without blocking, and the base implementation
always returns 0.

Instead, leverage the fact that parseDelimitedFrom() returns null if the
stream is at EOF.

PiperOrigin-RevId: 602257598
Change-Id: I61e51774611196fb44745dc0aa2dc836b41fcd68
      36e65215
  11. Jan 30, 2024
  13. Jan 29, 2024
  15. Jan 28, 2024
    • bazel.build machine account's avatar
      [7.1.0] Force output checking for incremental run commands without the bytes. (#20988) · 0ee114f8
      bazel.build machine account authored 
      When building without the bytes, outputs are only materialized when
either (1) an action prefetches them, or (2) they've been explicitly
requested. When both --remote_download_minimal and
--noexperimental_check_output_files are set, this presents a problem for
a build command followed by a run command for the same target: the build
command won't download the outputs and the run command won't check for
their presence, proceeding without them. A non-incremental run command
works, because the outputs are considered top-level even in minimal
mode.

This is only a problem for a run command because it exists outside of
action execution, and doesn't get a chance to prefetch inputs; it would
have been better to implement the run command by injecting a specially
crafted action into the build graph, but that will have to wait for
another day. The present fix might theoretically slow things down if
output checking is truly unnecessary, but I doubt that would cause a
significant regression in practice.

Fixes #20843.

Closes #20853.

Commit
https://github.com/bazelbuild/bazel/commit/2f899ef8b39935d9ca131b71a24e67ef286bc378



PiperOrigin-RevId: 597909909
Change-Id: I66aedef4994fbda41fe5378c80940fa8ba637bfd

Co-authored-by: default avatarTiago Quelhas <tjgq@google.com>
      0ee114f8
  17. Jan 27, 2024
  19. Jan 26, 2024
  21. Jan 25, 2024
    • bazel.build machine account's avatar
      [7.1.0] Also report cycles involving WORKSPACE from BzlmodRepoCycleReporter (#21013) · fa0660a9
      bazel.build machine account authored 
      Work towards #20942

On the referenced bug, this prints:
```
ERROR: Circular definition of repositories generated by module extensions and/or .bzl files:
.-> repository mapping of @@
|   WORKSPACE file
|   //python:pip.bzl
|   //python/pip_install:requirements.bzl
|   //python:defs.bzl
|   //python:py_import.bzl
|   //python:py_info.bzl
|   @@_main~internal_deps~rules_python_internal//:rules_python_config.bzl
|   @@_main~internal_deps~rules_python_internal
|   extension 'internal_deps' defined in //python/private/bzlmod:internal_deps.bzl
`-- repository mapping of @@
ERROR: Error computing the main repository mapping: cycles detected during computation of main repo mapping
```

Closes #20958.

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



PiperOrigin-RevId: 601183514
Change-Id: If321005b1f6918117d0f5b5763ae2bda4d8e34f1

Co-authored-by: default avatarFabian Meumertzheim <fabian@meumertzhe.im>
      fa0660a9
    • Salma Samy's avatar
      [7.1.0] Remove user specific path from the lockfile (Fixes #19621) (#21009) · 9d12d79e
      Salma Samy authored 
      If a local registry is specified using a workspace placeholder, the
lockfile stores location details of the files with resolved workspace
information, including user-specific paths.

To fix that: Updating the logic to use the workspace placeholder
%workspace% during lockfile writing and reverting to the resolved paths
when reading.

PiperOrigin-RevId: 600876401
Change-Id: I6162d8e8f1fe5e29b7899fc5bb218d1b6be926d0
      9d12d79e