Release 7.5.0 #1
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JSON-based merge conflict resolution for `MODULE.bazel.lock` can end up producing entries with, e.g., both a `general` and an `os:Linux` factor result when the OS/arch dependence of the extension changes. `BazelLockFileModule` now invalidates each factor result individually. Also sort the extension factors. Closes #22378. PiperOrigin-RevId: 635913837 Change-Id: I0064098806c856f16e8f4c0270f609f06cebc945 Commit c4092e9 Co-authored-by: Fabian Meumertzheim <[email protected]>
Fixes #14418 Closes #22420. PiperOrigin-RevId: 635740423 Change-Id: Iffd4d172c4175be2e1b6cfad04ddad2759adb987 Commit 01a90d6 Co-authored-by: Keith Smiley <[email protected]>
…gs (#22467) Targets tagged with `local` or `no-sandbox` and `no-remote` can't successfully use path mapping and thus have it disabled implicitly. Closes #21921. PiperOrigin-RevId: 635832339 Change-Id: Ib5cac0b202cbcd1704410f06fa3cda645581b849 Commit 46dce83 Co-authored-by: Fabian Meumertzheim <[email protected]>
Co-authored-by: hvd <[email protected]> Co-authored-by: Googler <[email protected]>
The following validation checks were not enforced due to backwards compatibility concerns, but ended up crashing Bazel when invalid labels made it into the lockfile, which is enabled by default. We might as well enable them now: * Fail if a label passed to `use_extension` is not valid * Fail if a label passed to the `patches` attribute of an override is not valid or points to a repo other than the main repo Work towards #21845 Closes #22487. PiperOrigin-RevId: 636255834 Change-Id: I55dda374cd1716e514c4d78642479b136fd3ad43 Commit cdace8f Co-authored-by: Fabian Meumertzheim <[email protected]>
…ine options (#22507) Examples: ``` $ bazel build //src:bazel-dev --experimental_remote_cache_evection_retries=5 ERROR: --experimental_remote_cache_evection_retries=5 :: Unrecognized option: --experimental_remote_cache_evection_retries=5 (did you mean '--experimental_remote_cache_eviction_retries'?) $ bazel build //src:bazel-dev --notest_kep_going ERROR: --notest_kep_going :: Unrecognized option: --notest_kep_going (did you mean '--notest_keep_going'?) Closes #22193. PiperOrigin-RevId: 636258381 Change-Id: Ie81344caa14054e1d328d5a6e9b94da506d6a577 Commit 0e9287f Co-authored-by: Fabian Meumertzheim <[email protected]>
Fixes #22489 Closes #22493. PiperOrigin-RevId: 636310898 Change-Id: If2fb41fd8d51f15aa1047cb62d55035e81187e41 Commit 792d17c Co-authored-by: Fabian Meumertzheim <[email protected]>
…he. (#22500) So that the last task won't try to shutdown the remoteCache, otherwise, might cause deadlocks. Fixes #21568. PiperOrigin-RevId: 635746896 Change-Id: Ic321216dd0bda05ef1ad18367c8ebbcd1a1d272c Commit a804fb1 Co-authored-by: Googler <[email protected]>
…22518) The retry doesn't work if the ContentLengthMismatchException is wrapped in an IOException. PiperOrigin-RevId: 636107102 Change-Id: I721e0be325dfd7c4e8a3dd697f5d513f42bcb7aa Commit 758f399 Co-authored-by: Googler <[email protected]>
Closes #22513. PiperOrigin-RevId: 636650432 Change-Id: Ic9af576b7f24af92ff8c3f0fbb1167d6db1687ea Commit 9dcec10 Co-authored-by: Fabian Meumertzheim <[email protected]>
This is a continuation of #22155 that adds the newly added 'remote_files' attribute for http_archive to the bzlmod functionality. The end goal is to then update BCR to this new functionality to overlay files rather than use patch files when providing MODULE/WORKSPACE/BUILD files. bazelbuild/bazel-central-registry#1566 has a good discussion of the rationale. Co-authored-by: Fabian Meumertzheim <[email protected]> Closes #22349. PiperOrigin-RevId: 636682112 Change-Id: Ief070985598a7c0f427a98cd3daeb69a0984f7be Commit c4167e3 Co-authored-by: Farid Zakaria <[email protected]>
…xtensions (#22537) Catches a common gotcha of referencing a repo created by an extension elsewhere in an extension without a `use_repo` and provides actionable advice to user. This prevents lockfile corruption caused by non-visible labels. The same validation is applied to labels in tag attributes. Fixes #21845 Closes #22495. PiperOrigin-RevId: 636939357 Change-Id: Ib779207502f7767e4e8d3abc55ba7470f75821b9 Commit aa436c3 Co-authored-by: Fabian Meumertzheim <[email protected]>
…is closed (#22539) Otherwise, a subprocess that consumes the stdin in its entirety can never terminate. PiperOrigin-RevId: 635774207 Change-Id: I134ddd1fee50faccb8ddb8400dbb11ce6a354c05 Commit b3f5c62 Co-authored-by: Googler <[email protected]>
We now generate fixup commands targeting `include()`d segments in addition to the root MODULE.bazel file itself. Fixup commands are grouped by file, and then passed to Buildozer using `-f -` (i.e. multiple commands for multiple files, passed in using stdin). - For repos to add, we find the first usage with the correct prod/dev type and add them there. - For repos to remove, we remove them from whichever usage had them. - At the end, all module files and included segments are formatted. Fixes #22063 Closes #22455. PiperOrigin-RevId: 636680730 Change-Id: Id894a449d8d1cdf39271ea3a724a91aebc51befb
When loaded as a `data` dependency (e.g. for `dlopen`), the runfiles of a `cc_shared_library` now contain the `_solib` symlinks of precompiled dynamic library dependencies instead of the symlink targets. Work towards #21833 Closes #21882. PiperOrigin-RevId: 637807250 Change-Id: I7ea2858c8cc9b5072beecf01d9dd49f8385aaebd Commit 75e5d2f Co-authored-by: Fabian Meumertzheim <[email protected]>
Fixes #22404 RELNOTES: Changes to environment variables read via `getenv` now correctly invalidate module extensions. Closes #22498. PiperOrigin-RevId: 637058337 Change-Id: Id4aaa4155a728452472eedae4a59c8d29456e512 Co-authored-by: Fabian Meumertzheim <[email protected]>
Instead of ``` ERROR: An error occurred during the fetch of repository 'mydep~': Traceback (most recent call last): File "/private/var/tmp/_bazel_fmeum/7d8a4807d1079f03870ba5776e9ca66b/external/bazel_tools/tools/build_defs/repo/http.bzl", line 142, column 45, in _http_archive_impl download_info = ctx.download_and_extract( Error in download_and_extract: java.io.IOException: Bad URL: invalid ERROR: <builtin>: fetching http_archive rule //:mydep~: Traceback (most recent call last): File "/private/var/tmp/_bazel_fmeum/7d8a4807d1079f03870ba5776e9ca66b/external/bazel_tools/tools/build_defs/repo/http.bzl", line 142, column 45, in _http_archive_impl download_info = ctx.download_and_extract( Error in download_and_extract: java.io.IOException: Bad URL: invalid ERROR: Error computing the main repository mapping: error during computation of main repo mapping: java.io.IOException: Bad URL: invalid ``` print ``` ERROR: An error occurred during the fetch of repository 'mydep~': Traceback (most recent call last): File "/private/var/tmp/_bazel_fmeum/7d8a4807d1079f03870ba5776e9ca66b/external/bazel_tools/tools/build_defs/repo/http.bzl", line 142, column 45, in _http_archive_impl download_info = ctx.download_and_extract( Error in download_and_extract: java.io.IOException: Bad URL: invalid ERROR: Error computing the main repository mapping: error during computation of main repo mapping: java.io.IOException: Bad URL: invalid ``` Fixes #22520 Closes #22522. PiperOrigin-RevId: 637954405 Change-Id: Iec55a5cf7cb287f692bd26fc1937379aa8b1853f Commit aa67e4c Co-authored-by: Fabian Meumertzheim <[email protected]>
There were 2 things with the previous implementation that needed to be improved here: 1. Apple Clang has a bug where it doesn't pass module compiler flags to the underlying -cc1 invocation, so we have to manually pass them directly to that invocation with -Xclang 2. The previous search script was too aggressive and slow for macOS. The macOS SDK has tons of files that aren't headers, and tons of symlinks pointing to other files within the SDK. This adds a fork in the script to run a version that works with Apple SDKs. The time difference on my machine is 41s->6s. 6s is still pretty long so if desired we can put this behavior behind an env var for users to opt in with. I've added a hermetic version of this to the apple_support toolchain, but similar to the Linux setup here the modulemap file includes absolute paths. Closes #22259. This reverts commit 1f1b4fd. Partial commit for third_party/*, see #22475. Change-Id: I801121e36de1504c17adfa4736c49c88d470fec0 Signed-off-by: Hee Cha <[email protected]> Commit de0a37c Signed-off-by: Hee Cha <[email protected]> Co-authored-by: Keith Smiley <[email protected]>
This greatly simplifies the code flow. Instead of using `volatile` and resorting to some very unsavory workarounds, we can simply make sure only one thread is changing `state.workerFuture` using plain old synchronization, and on memory pressure, make absolutely sure that the state object is cleaned up after we remove it from the central state cache. This goes against the advice introduced in 8ef0a51; the wording for `SkyKeyComputeState#close()` has been updated. Also changed the "retry on cancellation" logic from using recursion to using a `while`-loop for better clarity around nested `finally` blocks. Fixes #22393. PiperOrigin-RevId: 637975501 Change-Id: Ied43f0310ec8953f4ff1c2712fe07b8ccbd6c184 Commit de4d519 Co-authored-by: Googler <[email protected]>
…uild var… (#22557) …iables This change prepares for C++ path mapping, which also needs to map include directories of generated headers. It may, as a side effect, reduce memory usage slightly by possibly reusing nested set instances retained elsewhere. Work towards #6526 Closes #22463. PiperOrigin-RevId: 636886343 Change-Id: Ic93d6439a51f37f44bb2ac67d0813c48c0c4a8bd Fixes #22533 Co-authored-by: Googler <[email protected]>
There were 2 things with the previous implementation that needed to be improved here: 1. Apple Clang has a bug where it doesn't pass module compiler flags to the underlying -cc1 invocation, so we have to manually pass them directly to that invocation with -Xclang 2. The previous search script was too aggressive and slow for macOS. The macOS SDK has tons of files that aren't headers, and tons of symlinks pointing to other files within the SDK. This adds a fork in the script to run a version that works with Apple SDKs. The time difference on my machine is 41s->6s. 6s is still pretty long so if desired we can put this behavior behind an env var for users to opt in with. I've added a hermetic version of this to the apple_support toolchain, but similar to the Linux setup here the modulemap file includes absolute paths. Closes #22259. This reverts commit 1f1b4fd. Closes #22475. PiperOrigin-RevId: 637969838 Change-Id: I7d4940a820e3741836239493222ba8d06c4d70e4 Commit 6abdd2a Co-authored-by: Keith Smiley <[email protected]>
- Fixed the leak of `remote_patches` URLs for downloaded the source archive. - Compute auth for required URLs only Fixes #22201 Closes #22517. PiperOrigin-RevId: 638300996 Change-Id: Ib76e3284f209d2314844cfd662ac8eadba785fae Commit 5986420 Co-authored-by: Yun Peng <[email protected]>
MSVC fails if `/external:I <some_path>` is broken into two lines in `.param` files. This is avoided by using the alternative `/external:I<some_path>` form. Fixes #22614 Closes #22616. PiperOrigin-RevId: 640055579 Change-Id: I5fda2714dc479fd76f22e2f8562dddbdfcdb9a18 Commit 759fe7d Co-authored-by: Fabian Meumertzheim <[email protected]>
On an incremental build with `--watchfs`, the `handleDiffs` span in the timing profile is now almost fully explained by subspans. Closes #22622. PiperOrigin-RevId: 640084976 Change-Id: Iab7c9f22bab5e53cfab1d39dc0b3f2a697453540 Commit f4b4537 Co-authored-by: Fabian Meumertzheim <[email protected]>
This change introduces the flag `--experimental_inmemory_sandbox_stashes` to track in memory the contents of the stashes stored with `--reuse_sandbox_directories=true` With the old behavior Bazel has to perform a lot of I/O to read the contents of each stash before reusing it in a new action. Essentially, it checks every directory and subdirectory in the stashed sandbox to find out which files are different to the inputs of the new action about to be executed. With in-memory stashes we associate each stash to the symlinks that needed to be created for that action. We also store the time at which these symlinks were created. In a background thread after the action has finished executing we stat every directory and for the ones that have changed (this should be rare) we update the contents. Because we only read the contents of the directories that have changed we do much less I/O than before. If an action purposefully changes a sandbox symlink in-place, this won't be detected by statting the directory. I don't know any use case for this since the symlink itself is an implementation detail to achieve sandboxing. For this reason, manipulation of sandbox symlinks in-place is not supported. Depending on the build this change might have a significant effect on memory. It should generally improve wall time further in builds where `--reuse_sandbox_directories` already improved wall time. This change also introduces a minor optimization which is to associate each stash with the target that it was originally created for. When a new action wants to reuse a stash and there is more than one available, it will take the stash whose target is closest to its own. This is done with the assumption that targets that are closer together in the graph will have more inputs in common. Fixes #22309 . Closes #22559. PiperOrigin-RevId: 640142481 Change-Id: Iece2d718df47f403e2fe91c1bd887604eceee8ee Commit 1c0135c Co-authored-by: Pedro Liberal Fernndez <[email protected]>
…#22647) **The Issue** Some external users reported the following sequence: 1. Build starts 2. Build interrupted very early on 3. Another build is started. The command line says "A previous command is running", while the server is stuck. What happened under the hood: The issue could be reproduced very reliably by placing a breakpoint here[1] and interrupt the build. Bazel is in the middle of the recursive `IncrementalPackageRoots.registerAndPlantMissingSymlinks` method when it received the interruption. One important detail: we only add a NestedSet to the `donePackagesRef` set when the _method_ is done successfully. When there's an interruption, we always bail early and never actually reach this line where the NestedSet is added to the set[2]. Without deduplication, this could lead to what feels like an finite loop if the packages are structured like so: ``` [[A], [B, [A]]] ``` In this case, NestedSet `[A]` represents a common child of many NestedSets and would be repeated again and again. We've indeed observed this in a real build, making it unable to finish within any reasonable timeframe. **The Solution** It was overly restrictive to only commit a NestedSet into the de-dup set _after_ all of its symlinks have been planted. It only makes sense if we're planting the symlinks for multiple top-level targets at the same time and want to avoid the situation where a top-level target is allowed to enter execution without all of its symlinks planted. We're already avoiding this situation by design by planting the symlinks for 1 single top-level target at a time. To avoid the near-infinite loop caused by a repeated NestedSet, we add each NestedSet to the de-duplication set the very first time it's seen. **Changes in this CL** - [Bug-fixing] Add a NestedSet to the de-duplication set the very first time it's seen. - [Code simplicity] 1 single blocking `Future.get()` instead of 1 for each recursive layer. Fixes #22586. --- [1] https://github.com/bazelbuild/bazel/blob/193b114287b3e20850a4b106b889771dfa63a601/src/main/java/com/google/devtools/build/lib/skyframe/IncrementalPackageRoots.java#L253 [2] https://github.com/bazelbuild/bazel/blob/193b114287b3e20850a4b106b889771dfa63a601/src/main/java/com/google/devtools/build/lib/skyframe/IncrementalPackageRoots.java#L256 PiperOrigin-RevId: 640524271 Change-Id: I63c39d7c8f27abaf9229396af1424e775cf5f85f Commit d705928 Co-authored-by: Googler <[email protected]>
This is a partial cherry-pick of 417c6b8 which excludes the changes to `oneversion` itself, which is built and released for Bazel 7 as part of java_tools: * Avoid passing --whitelist to one_version if no allowlist is configured in the toolchain as it isn't supported by the Bazel version of oneversion yet. * Document the one_version flags. * Clean up tests not updated after recent rules_java releases. Fixes #22576
Should fix the following crash observed in the wild:
```
FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.RuntimeException: Unrecoverable error while evaluating node 'RepoSpecKey{[email protected], registryUrl=https://bcr.bazel.build/}' (requested by nodes 'com.google.devtools.build.lib.bazel.bzlmod.BazelModuleResolutionValue$$Lambda/0x00000008005fd220@38aba3ca')
at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:550)
at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:414)
at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
Caused by: java.lang.NullPointerException: Cannot invoke "com.google.devtools.build.lib.events.StoredEventHandler.replayOn(com.google.devtools.build.lib.events.ExtendedEventHandler)" because "this.bazelRegistryJsonEvents" is null
at com.google.devtools.build.lib.bazel.bzlmod.IndexRegistry.getBazelRegistryJson(IndexRegistry.java:336)
at com.google.devtools.build.lib.bazel.bzlmod.IndexRegistry.getRepoSpec(IndexRegistry.java:295)
at com.google.devtools.build.lib.bazel.bzlmod.RepoSpecFunction.compute(RepoSpecFunction.java:52)
at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:461)
... 7 more
```
Closes #22639.
PiperOrigin-RevId: 640572972
Change-Id: Id24ce3476df55fa75d6f3291e100b1037f0793f4
Commit
6936150
Co-authored-by: Fabian Meumertzheim <[email protected]>
…4228) This PR removes the DownloadManager from the registry factory implementation. As the registry created by the factory is cached by the SkyFunction mechanism, the DownloadManager instance was living too long - it is supposed to be re-created for every command instantiation to respect changes in command line options, but for the registry, it ignored those changes. Instead, the DownloadManager is set directly into the affected SkyFunctions that require access to it. This way, the per-command DownloadManager instance is correctly used. This fixes #24166. Note for reviewers: This is my first time touching code with SkyFunctions, so I don't really know what I'm doing. Closes #24212. PiperOrigin-RevId: 693644409 Change-Id: I7b16684e52673043615290d114f078ab7ab99fcf Co-authored-by: Cornelius Riemenschneider <[email protected]>
Release Notes:
python: fix bazel py_test testSmoke for Python 3.11+ The test was failing because the `b.py` file couldn't be imported because, starting with Python 3.11, the `PYTHONSAFEPATH` environment variable (set by the bootstrap startup) is respected. This setting inhibits the default Python behavior of adding the main script's directory to sys.path. To fix, use `py_library.imports` to explicitly add the necessary directory to `sys.path`. Fixes #20660 Closes #20738. PiperOrigin-RevId: 595498775 Change-Id: I0c9521b210fe9e2c40692727fc87d41995e0968a Commit 9b027c8 No public description PiperOrigin-RevId: 694487395 Change-Id: I3f3e154ebfa932721d917661d61a878477a8e574 Commit be2186f --------- Co-authored-by: Richard Levasseur <[email protected]> Co-authored-by: Googler <[email protected]>
This helps the HTTP downloader better cope with filesystems where unlink is non-atomic. Closes #24295. PiperOrigin-RevId: 697920434 Change-Id: I91b4dbf07a2efdca07c0310e15aac5f4d89c4091 Commit 99a27f6 Co-authored-by: Simon Thornington <[email protected]>
No longer works with python 3.12 or later. PiperOrigin-RevId: 694480477 Change-Id: Ia662c8fb5511e9c551448730800240ab627463be Commit 5b54c74 Co-authored-by: Googler <[email protected]>
…SocketException (#24722) Fix for #24530 --experimental_repository_downloader_retries will now retry on `SocketException` in addition to `ContentLengthMismatchException` Closes #24608. PiperOrigin-RevId: 704633572 Change-Id: Idd1fcbb768c9dabed596fe15d8ae9260ef3e895d Commit 459bb57 Co-authored-by: Pareesh Madan <[email protected]>
wofstream cannot be constructed from wstring according to the standard https://en.cppreference.com/w/cpp/io/basic_ofstream/basic_ofstream. Closes #24703. PiperOrigin-RevId: 707172911 Change-Id: I973f9560c5b20748e4635cd757f53fff9c8ef0c5 Commit 5b35276 Co-authored-by: Boleyn Su <[email protected]> Co-authored-by: Yun Peng <[email protected]>
Work towards #23497 Work towards #24389 Closes #24431. PiperOrigin-RevId: 698846634 Change-Id: I3fb2d46597b225833a918af9731665bb276322dd Commit 27a5e45 Co-authored-by: Fabian Meumertzheim <[email protected]> Co-authored-by: Ian (Hee) Cha <[email protected]> Co-authored-by: Yun Peng <[email protected]>
…sults di… (#24667) …rectly to a file This is a proposed fix for #24293 This speeds up a fully warm `bazel query ...` by 23.7%, reducing wall time from 1m49s to 1m23s ``` $ time bazel query '...' --output=streamed_proto > queryoutput4.streamedproto real 1m48.768s user 0m27.410s sys 0m19.646s $ time bazel query '...' --output=streamed_proto --output_file=queryoutput5.streamedproto real 1m22.920s user 0m0.045s sys 0m0.016s ``` _💁♂️ Note: when combined with #24305, total wall time is 37s, an overall reduction of 66%._ Closes #24298. PiperOrigin-RevId: 700583890 Change-Id: Ic13f0611aca60c2ce8641e72a0fcfc330f13c803 Commit 791e1f7 Co-authored-by: Keith Lea <[email protected]> Co-authored-by: Yun Peng <[email protected]>
TEST: bazel build --platforms=//:windows_x86_64 --extra_toolchains=@llvm_mingw_linux_x86_64//:cc-toolchain-linux_x86_64-windows_x86_64 //src/tools/launcher:launcher Closes #24752. PiperOrigin-RevId: 711358608 Change-Id: Iedacad9b959427ed5d4598e0ea594cb25b8845c8 Commit a4bb254 Co-authored-by: Boleyn Su <[email protected]>
auto does not exist in Bazel 4, 5, 6 or 7. I'm not sure if was there before but in any of these versions when trying it the following error appears ERROR: While parsing option --dynamic_mode=auto: Not a valid dynamic mode: 'auto' (should be off, default or fully) Fixes: #20707 Closes #20705. PiperOrigin-RevId: 630063050 Change-Id: Ib0b0427268a885d6ffc62c81183b6dd24a6dc517 (cherry picked from commit a70a28f)
…4847) This allows IDEs to query for the direct dependencies of the root module as well as how they can refer to them from the point of view of the root module. Also always emit `name` and `version` so that consumers don't have to know how to parse module keys. Work towards #22691 Closes #23787. PiperOrigin-RevId: 693453084 Change-Id: Ie3fd5e89301d8e83d0eaa686188634923853f01a (cherry picked from commit 1003d2c) Fixes #24678
This protects against an integer overflow which could occur for large key list size and large thread counts. Regrettably, it's difficult to write a regression test for this scenario, as exercising this overflow requires lots of time and heap, so it would be a performance regression to our test suites. Fixes #19445 PiperOrigin-RevId: 595420516 Change-Id: Ic0a475a6a273c50fe9895dd0852fa5b062859cb2 Commit 3e373d0 Co-authored-by: Googler <[email protected]>
Fixes #24730 Closes #24735. PiperOrigin-RevId: 713606521 Change-Id: If8578fcdfc30dcbfb6af283089614f3364eb30d8 Commit e78bab5 Co-authored-by: Fabian Meumertzheim <[email protected]>
This makes it easier for users to discover that a module hasn't been found because its absence was recorded in the lockfile during a previous build. Fixes #24803 Closes #24804. PiperOrigin-RevId: 713142592 Change-Id: Id541f5710481bd947c09d8dba315d683a1666b1c (cherry picked from commit 6061e5e) Fixes #24805
…#24912) The jar can be supplied separately as it needs to be passed to the `-javaagent` JVM arg anyway. Also update the recommended version for compatibility with Java 21. Fixes #24782 Closes #24783. PiperOrigin-RevId: 714057306 Change-Id: Ic8d47562f15344ed16d0af5d3242937d2ee53b22 (cherry picked from commit b59fbee) Fixes #24788
…...` (#24908) Fixes #24882 Closes #24883. PiperOrigin-RevId: 714854122 Change-Id: I5e48e84f88606320223a9969e8367924aeeb13dd Commit 6423b04 Co-authored-by: Fabian Meumertzheim <[email protected]>
…repository (#24900) Fixes #24770 Closes #24887. PiperOrigin-RevId: 714107497 Change-Id: Ib914aa54b2afa2a90fcce2f2263b9c1b2d2c193c Commit 6a141ea Co-authored-by: Dave Roth <[email protected]>
This makes it possible to retroactively link an execution log file to a particular build. Closes #24790. PiperOrigin-RevId: 715017597 Change-Id: Ia8f6a3677a165a9f428b59ab8a19587a357b8803 Commit fd6a983 Co-authored-by: Fabian Meumertzheim <[email protected]>
PiperOrigin-RevId: 715819891 Change-Id: I1c2e582a3d4c6e87e5c76837abb7a175eed3e850 (cherry picked from commit c570f97) Fixes #24933 Co-authored-by: Googler <[email protected]>
…ck (#24941) ... 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. #24763 PiperOrigin-RevId: 715734718 Change-Id: Id1a1a59d8b5f3e91a7ae05a73663ff37eee6d163 Fixes #24920.
This option, which is different from the startup option of the same name, has no effect and doesn't even show a warning, which can be confusing. Closes #24953. PiperOrigin-RevId: 717853503 Change-Id: I8d7d1229f692007c4350b6c15526b7a95bbed5ef Commit 79508be Co-authored-by: Fabian Meumertzheim <[email protected]>
… minor releases with no RELNOTES tags (#25025) PiperOrigin-RevId: 718504556 Change-Id: I54f42e07721935c44a6f2a314b59864d6433d865 Commit c38bed0 Co-authored-by: Googler <[email protected]>
…etadata (#25057) ea4ad30 added an action as context for prefetches with BwoB, but assumed that all callers would use the prefetcher for inputs to locally executed actions. However, since then, it has also been used to download outputs of completed actions that have been explicitly requested (e.g. as outputs of top-level targets or those matching the regex path patterns). This resulted in downloads with a `prefetcher` action ID and action details for the action that produced the file, rather than consumed it, resulting in confusing situations for observability tools. This is fixed by separately tracking the reason for the fetch. Using an action ID of `output` when the action has the requested file as an output, and "input" when the action has the requested file as an input. Closes #25040. PiperOrigin-RevId: 719246746 Change-Id: Ib95ff65ba68112b1a38ab3022e5b1a19ef74cc9f (cherry picked from commit 998e762) RELNOTES: CAS requests made when Bazel downloads a blob with Build without the Bytes enabled now provide metadata with an action ID of `input` if the blob is downloaded as the input to a local action and `output` if it is a requested action output.
…ation extraction (#25093) Previously, we only supported attribute types which could be defined for Starlark rules, with the result that a cherry-pick in the 7.x branch exposing a formerly native-only attribute type to Starlark broke Stardoc: bazelbuild/stardoc#277 Instead of picking and choosing, let's support all attribute types, same as we already do in Bazel 8 and newer. Cherry-pick of a subset of changes in commit 1ce4ab1 PiperOrigin-RevId: 675169119 Change-Id: I6541a5eb99d6257339032850d360d2da4bd5aeb4
…gs (#25115) The mapping of an apparent name in a module extension tag's `attr.label` attribute to the corresponding canonical name has to be recorded in the lockfile so that instantiated repo rules don't reference the stale repos. Fixes #25063 Closes #25067. PiperOrigin-RevId: 720592796 Change-Id: Ia202ca4a8482a81da8085ee18ecaca5fe233bddb --------- Co-authored-by: Fabian Meumertzheim <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.