[8.0.0] Re-enable symbolic macro attribute inheritance and remove --experimental_enable_macro_inherit_attrs flag (#24445)

After
https://github.com/bazelbuild/bazel/commit/a2f1f58cdff07d240c9f715d5091672bd9abd03f,
macro inheritance API is in a good shape - and without macro
inheritance, we wouldn't have any good way for symbolic macros in Bazel
8 to use `testonly`.

Considering for how little time the
--experimental_enable_macro_inherit_attrs existed, and that no
references to it was marked experimental, it seems safe to remove it
directly without graveyarding.

Cherry-pick of

https://github.com/bazelbuild/bazel/commit/a39d18122ae824697691813a103ccb65871ff033

RELNOTES: Re-enable symbolic macro attribute inheritance.
PiperOrigin-RevId: 698884636
Change-Id: I7f682949e96b6739e12d8f569a87ef2daf0ea41c

Contains cherry-picks of:
* dfdbe77f
* d99595f9
* 3d60f1cf



RELNOTES: `archive_override` now accepts all attributes usable with
`http_archive`; similar for `git_override` and `git_repository`.

---------

Co-authored-by: Googler <cushon@google.com>

Fixes issue where server process would "cache" environment variables.
Broken since 3ebf658c (v5).

Closes #24433.

PiperOrigin-RevId: 698847238
Change-Id: I51d4ec811ee9d78717ff816d9988b4ad0f533265

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



Co-authored-by: Jordan Mele <jordan.mele@outlook.com.au>

Work towards #23497
Work towards #24389

Closes #24431.

PiperOrigin-RevId: 698846634
Change-Id: I3fb2d46597b225833a918af9731665bb276322dd

Commit
https://github.com/bazelbuild/bazel/commit/27a5e4593fb661518aaa1bad96ff1fc5257733eb



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

Enable autoloading of `java_common`

PiperOrigin-RevId: 698696053
Change-Id: Id64c3b024294d97ebc9aed808d6e210065f79825 (cherry picked from
commit 06c1ae9f)

Make the buildkite log viewable again

Addressing
https://buildkite.com/bazel/bazel-bazel/builds/30048#01930c44-35d3-4c13-aa34-c7d610643e8d



PiperOrigin-RevId: 694528361
Change-Id: I17bde53d954e4a6991fd4af9b563736c5c813011

Co-authored-by: Googler <pcloudy@google.com>

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

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



---------

Co-authored-by: Googler <jingwen@google.com>
Co-authored-by: Googler <cushon@google.com>

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

Bazel exposes BUILD files (and protos) that use protobuf in
@bazel_tools. Until this is used in WORKSPACE mode, the name needs to
stay com_google_protobuf.

Replace @protobuf// with @com_google_protobuf. This is the trivial
change.

Fix WORKSPACE.suffixes. They were generated with @protobuf, instead of
@com_google_protobuf.

Fix autoloads to use @com_google_protobuf. The WORKSPACE.suffix files
were obscuring the problem here.

Upgrade rules_cc to 0.0.13, rules_java to 8.3.1, those are the first
using again @com_google_protobuf.

Upgrade protobuf to 29.0-rc3. Matches MODULE.bazel and has rules
implementation.

Fixes: https://github.com/bazelbuild/bazel/issues/24401
PiperOrigin-RevId: 698388130
Change-Id: Ib9d999c3b320eb409744f0775fe237aae1da5dc2

Some `get*` methods worked with apparent repo names, others didn't,
which is a hurdle to contributions in this area (as observed while
working on #24328).

Closes #24329.

PiperOrigin-RevId: 697548136
Change-Id: I24c3624875d1d1110ee8685656b88fffe3be6d95 
(cherry picked from commit 9534199d)

Closes #24347

*** Reason for rollback ***

This breaks rules_go and rules_swift because they refer to themselves by
alias depot names: https://github.com/bazelbuild/bazel/issues/24375

*** Original change description ***

In AppleBootstrap.java give several rule repos access to apple_common
that need it, and activate the access restriction independent of
INCOMPATIBLE_STOP_EXPORTING_LANGUAGE_MODULES

PiperOrigin-RevId: 698310431
Change-Id: I88973163cadca29021af9575d410fcae1eb6c066

Rollback of https://github.com/bazelbuild/bazel/pull/24360 on
release-8.0.0

Cherry-pick of:

f54c8531
b1c6ad32
ef8dab17

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

* Use Latin-1 in many native file write rules for consistency with the
internal encoding.
* Use Latin-1 for the resolved repository file and the JSON profile.
* Fix `unused_input_list` handling of non-ASCII characters in file
names.
* Flip the `legacy_utf8` parameter of `repository_ctx.file` to `False`
and make it a no-op. With the previous default, any non-ASCII characters
would be written out as double encoded UTF-8, which is not a useful
choice.
* Change `repository_ctx.template` to operate on raw bytes for
consistency with `repository_ctx.read` and to fix substitution with
non-ASCII keys/values.
* Move some usages of `UTF_8` closer to their usage site to clarify why
they are correct.
* Fixes parsing of dependency files with Unicode character contents
(`/showIncludes` and `.d` files)

Closes #24182.

PiperOrigin-RevId: 698111811
Change-Id: Ie43bab9eb5963bf81690dd8985d358f544a711c9 (cherry picked from
commit 3fdec931)

Fixes #24242

Closes #24397.

PiperOrigin-RevId: 698091320
Change-Id: I17213f6984b38b9b89f3823ef4b6cabc43ac7b25

Even with `CLOCK_MONOTONIC`, we are still seeing Bazel servers fail to
start up occasionally due to start time being larger than end time. Make
this non-fatal by truncating to 0 and emitting a warning with start and
end time to facilitate further investigation.

Also flip the conditions for command and extraction wait time, which
previously were only included if *not* known.

Closes #24344.

PiperOrigin-RevId: 697932531
Change-Id: Ia124a1e10640fde909ec377ab493f1654b5933e7

Fixes #24395

This metric shouldn't be collected on Windows.

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

PiperOrigin-RevId: 698007958
Change-Id: I4d05e81e180467488a87a7839d879f916f9494b1

Commit
https://github.com/bazelbuild/bazel/commit/8f9a5038dd9dbaffffdde38e4f61d5afa0bd76ac



Co-authored-by: Googler <bangbang@google.com>

rules_proto is already a transitive dependency, this change makes sure a
Bazel 8 compatible version is used.

Addresses failures like:
https://buildkite.com/bazel/bcr-bazel-compatibility-test/builds/51#01933ece-5ec0-4279-9057-f928f1406e6b

PiperOrigin-RevId: 697832335
Change-Id: I785c8223c0463d85b7bcd1b5c42b390fdddf341c

Order doesn't matter for these inputs and sorting them can only help
decrease merge conflicts in the lockfile.

Closes #24367.

PiperOrigin-RevId: 697924458
Change-Id: Ie29e4c05204b974f10db571d61f38969411da03b

Commit
https://github.com/bazelbuild/bazel/commit/34cc02ae8e73a9a1d2f00277da09c27924dd626b



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

Fixes #24325

Closes #24326.

PiperOrigin-RevId: 697842646
Change-Id: Ied25448861c5133aae6f266000fe983625f48963

Commit
https://github.com/bazelbuild/bazel/commit/5141c06f62ed1e435dec40aaed1dfb98f2f9b399



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

aa7317f8 changed the canonical name of repositories generated by
`use_repo_rule`, which should have been accompanied by a bump of the
lockfile version.

Should fix
https://github.com/bazelbuild/bazel/pull/24171#issuecomment-2482949080

Closes #24363.

PiperOrigin-RevId: 697924369
Change-Id: I3b2876ea3fab86d5ab9c7e08f8c9ce607573c56c

Commit
https://github.com/bazelbuild/bazel/commit/71227bf00cf803f931f126ed5ad6df5b2a073a27



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

This contains the following 3 cherry picks, which I'm providing in one
PR because they must be applied in order:

1. Explicitly ban attribute inheritance from unexported rules/macros

Cherry-pick of

https://github.com/bazelbuild/bazel/commit/372980c4a7e68cfd0b6593172249b7c19c3fe3cb
PiperOrigin-RevId: 696954211
Change-Id: Ia205fe4e6686d51248c1389e1cf7b826650908e8

2. Force the default value of symbolic macro's optional inherited
attributes to None

Cherry-pick of

https://github.com/bazelbuild/bazel/commit/a2f1f58cdff07d240c9f715d5091672bd9abd03f

PiperOrigin-RevId: 697301269
Change-Id: I47563898c511a1f065d117f51a7a3a227e23260e

3. Update symbolic macro docs

Cherry-pick of

https://github.com/bazelbuild/bazel/commit/ebeab8ce6607f0ea8448178219c61a935535be6a

PiperOrigin-RevId: 697741975
Change-Id: I511580e75ad4366d7895d3a791c62d5f8dc756a4

Since Java 21, the internal `indexOf` method on String that accepts
start and end position is available as public API.

Closes #24333.

PiperOrigin-RevId: 697001722
Change-Id: I274b2ffd7a6d925531e1261f04bec5942d70fdf2

Commit
https://github.com/bazelbuild/bazel/commit/1c9f1dd19ccd26998cd0a8b000e3c6cd1f1066bb



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

Merge fix for #24066 into 8.0.0.

Closes tracking issue #24320.

I'm not sure why the automatic merge failed but it works locally, so
here goes.

In AppleBootstrap.java give several rule repos access to apple_common
that need it, and activate the access restriction independent of
INCOMPATIBLE_STOP_EXPORTING_LANGUAGE_MODULES.

PiperOrigin-RevId: 696999389
Change-Id: I000911fbef3b48039beb423e5ba1ab48059b8eeb

As long as Bazel internally represents strings as raw bytes "encoded" in
Latin-1, the same must be true for all Starlark files that may contain
file system paths.

Also includes changes to the Python test setup:
* `ScratchFile` now always writes files as UTF-8
* `RunProgram` encodes and decodes stdin/stderr/stdout as UTF-8
* `download` no longer leaks a file

Closes #24217.

PiperOrigin-RevId: 697550082
Change-Id: If7f3fc7ddace2cda5e1f8e48a65406aa54f2a6d8

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



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

CI runners have been updated in
https://github.com/bazelbuild/continuous-integration/commit/bd271932189c4b5e14ab17f1ff004c84b386e4be
to a Windows version that supports the approach taken in
7bb8d2b6 to start the JVM with UTF-8 as
the system encoding.

Closes #24270.

PiperOrigin-RevId: 697541108
Change-Id: I175a52b917667afe4129ad23ccb50171be1d2a59

Commit
https://github.com/bazelbuild/bazel/commit/27ab1ef1a2f1f78ecd81f56a113a1a69dec70648



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

Cherry-pick of 17cc9a42

PiperOrigin-RevId: 696766762
Change-Id: I01040ac41f89d7039198a95bb85339c1e4b9f6f8

* 3d9c90e6 (use Bazel 7.4.1)
* 00c5f1fa (docs for REPO.bazel)
* 2fd61151 (add .bazelbsp to .gitignore)

Roll forward of
https://github.com/bazelbuild/bazel/commit/a58fe3fa6b9ab1f7bfcd1ad8c94ab1f09a4cca39:
Fix most Unicode encoding bugs.

NEW: Relative to the original CL, the only changes are in
latin1_jni_path.cc and NativePosixFiles.java. In latin1_jni_path.cc, the
former implementation of GetStringLatin1Chars with a fallback for
strings with a UTF-16 coder is restored, with a BugReport sent whenever
any such string is detected. In NativePosixFiles.java, a private method
is added to be called from JNI to send the BugReport.

*** Original change description ***

Automated rollback of commit a58fe3fa

.

*** Reason for rollback ***

Causing crashes for internal software that uses Bazel's VFS stuff.

*** Original change description ***

Fix most Unicode encoding bugs

Bazel aims to support arbitrary file system path encodings (even raw
byte sequences) by attempting to force the JVM to use a Latin-1 locale
for OS interactions. As a result, Bazel internally encodes Strings as
raw byte arrays with a Latin-1 coder and no encoding information.
Whenever it interacts with encoding-aware APIs, this may require a
reencoding of the String contents, depending on the OS and availability
of a Latin-1 locale.

***

PiperOrigin-RevId: 696524066
Change-Id: Ifdddacc08c1a81ad719b1aeac2a93882cbafbcd2

Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

Closes #24243.

PiperOrigin-RevId: 696968080
Change-Id: I8ad1dbe03c54b3a8d13f699026140f114f75e928

Commit
https://github.com/bazelbuild/bazel/commit/54a9c0b7e8b23eb7338bf38022745e9095b80641



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

This CL simplifies RuleVisibility concatenation by inlining
concatWithElement() into concatWithPackage(). The latter was the only
caller of the former in production. The implementation no longer has to
handle the case where the RHS is public or private -- something that was
not needed in practice, but which was required in abstract for the
deleted method's API to be correct. It also now doesn't need to parse an
untrusted label, so there's no need to catch or throw EvalException.

concatWithPackage() is also made non-static, which looks nicer at the
call sites.

The validate() method is renamed to checkForVisibilityMisspelling(),
since that's the only thing it does now. (A previous CL removed its
other job of detecting formerly illegal combinations of public/private
visibility with other items in a list.)

Added an equals() and hashCode() while we're at it, to avoid depending
on singleton identity (I'm not sure whether @SerializationConstant lets
us assume that). It's based on just getDeclaredLabels() since that
should superset any information returned by getDependencyLabels().
Changed RuleVisibility from an interface to an abstract class too -- I
would've made it `sealed`, but the singleton PUBLIC and PRIVATE
anonymous subclasses prevent that and it's not worth making them named
classes.

MacroInstance.java
- Implement the TODO. (I went with "getDefinitionPackage" over
"getDefiningPackage" because the latter might be confused with the
package that defines the macro *instance*.)

MacroClass.java
- Condense to if-expr form now that the else branch is more concise.

RuleVisibilityTest.java
- Add pkg() helper for concatenation() test case.
- Remove assertEqual() now that we have a RuleVisibility#equals()
method.
- Rename "B" -> "B_PG" for clarity/contrast with "A" and "C".
- Delete test cases for concatWithElement that are no longer applicable
(where the RHS is public or private visibility)

Work toward https://github.com/bazelbuild/bazel/issues/23855.

PiperOrigin-RevId: 689400241
Change-Id: I6b7a1c9f87c4b3c9e5cd99d5dc4d906b5d798d28

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

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


Cherry-picks:
ebb27909
89e5e4a8
df5ab9da
a2ccbb90
09ca1f30
76963446
8ce16617
a1af43cd
93b62651
6b29bed6



---------

Co-authored-by: Googler <hvd@google.com>

[8.0.0] Put macro attribute inheritance behind an off-by-default --experimental_enable_macro_inherit_attrs flag (#24336)

We still have open questions about how macro attribute inheritance ought
to interact with the tracking of whether rule attributes were or were
not explicitly provided.

In effect, this re-opens
https://github.com/bazelbuild/bazel/issues/24066 Part of addressing
https://github.com/bazelbuild/bazel/issues/24319

RELNOTES: symbolic macro attribute inheritance is now marked
experimental; set --experimental_enable_macro_inherit_attrs flag to
enable it.

Commit

https://github.com/bazelbuild/bazel/commit/08beb210eddd35b703857e005d99c60b963e8e10

PiperOrigin-RevId: 696582223
Change-Id: I3d7cb434bf8fe2da9cd10019e6075990205e7153

Working towards #24335

Remove internal functions for Apple multi arch linking from apple_common
and instead expose functions needed by multi arch linking functions in
the repo.

---------

Co-authored-by: Yun Peng <pcloudy@google.com>

On windows, bazel will run the workspace_status_command, and receive
carriage return characters \r even if the workspace_status_command did
not include them.

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

PiperOrigin-RevId: 684055158
Change-Id: Idd3bd9c954d64b0a2d674dd7d90cf61c00955917

Previously, it was a no-op for a symbolic macro implementation function
to return a value. This CL makes it an evaluation error. (An explicit
`return` or `return <expr that evals to None>` statement is still
permitted.)

This is useful to enforce code clarity for symbolic macros. It may also
help catch errors sooner when migrating legacy macros to symbolic
macros. It also leaves the door open to having Bazel interpret the
return values of macros in specific ways in the future.

Fixes #24312.

PiperOrigin-RevId: 696153298
Change-Id: Ib317871664c2036cc24ea31bc0033ec691fd07c8

Commit
https://github.com/bazelbuild/bazel/commit/9e15ca3ca83120869b08bd5f45b27f110059e7e5



Co-authored-by: Googler <brandjon@google.com>

Should fix a server crash due to `unexpected exception type:
java.lang.InterruptedException` when interrupting a repo rule fetch.

Closes #24278.

PiperOrigin-RevId: 696043083
Change-Id: I44c95fb6b0043c89de8aa526c2ff9cf014ce9447

Commit
https://github.com/bazelbuild/bazel/commit/21d8b02fb26f89ec7bf3e7dd978c6ecf1d258ad0



Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

Before this, changing the value of `--enable_bzlmod` did not invalidate
the existing skyframe precomputed value as the instances were considered
the same/equal (see
`src/main/java/com/google/devtools/build/skyframe/AbstractInMemoryMemoizingEvaluator.java#pruneInjectedValues`)

Fixes https://github.com/bazelbuild/rules_python/issues/2387



PiperOrigin-RevId: 695696010
Change-Id: I136f2bec4e2c668d020f6cb1a7d3200f7523e5a0

Co-authored-by: Googler <hvd@google.com>

This ensures that this repository rule cannot be influenced by these
environment variables, particularly `GIT_DIR`, keeping the operation
limited to the directory specified by the `repository_ctx`.

In particular, this ensures that calling Bazel (e.g. `bazel test`) from
within a Git hook will work reliably. Git hooks set `GIT_DIR` (among
others), which can cause the repository rule's invocations of `git` to
misbehave. https://git-scm.com/docs/githooks

When using Git worktrees and calling Bazel from a Git hook, it has been
observed that `git_repository()` will not only fail, but will also set
`core.bare = true`, breaking the user's clone.

Fixes #24199.

Closes #24204.

PiperOrigin-RevId: 695642299
Change-Id: Id81e32194117cd8996408b236a6a88a20b14910b

Commit
https://github.com/bazelbuild/bazel/commit/89115d992d334cde8f0b8e207ed3fe8031a04907



Co-authored-by: Richard Woodbury <rpwoodbu@mybox.org>

Suggest the new flag instead of crashing when `--override_repository` is
applied to a non-existent repo with `--noenable_workspace`.

Fixes #22691

RELNOTES: The new `--inject_repository` flag can be used to add new
repositories via the CLI with `--enable_bzlmod`. Such repositories
behave as if they were declared by `local_repository` via
`use_repo_rule` in the root module.

Closes #23791.

PiperOrigin-RevId: 695848897
Change-Id: I92ed25261c92d07f289815fcf6a65485ff43f373

Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>