Add experimental lazy location expansion for Args

[fmeum]

Adds ctx.expand_location(input, targets, lazy = True), gated behind the new --experimental_lazy_location_expansion flag. Instead of an eagerly expanded string, it returns an opaque LazyLocationExpansion that can be passed to Args.add in place of the string.

Motivation

Eagerly expanded location strings bake artifact paths into strings that are retained in the analysis cache for the lifetime of the server (roughly 36 + length bytes per argument per action), and such strings can never be path mapped. The lazy form stores a compact recipe instead: a reference to the original input string (typically an attribute value retained by the rule anyway), an int[] of (start, end, mode) triples for the location expression sites, and the resolved artifacts — no string containing artifact paths is created during analysis at all, and no substrings of the input are retained either. That's ~36 bytes plus 12 bytes per expression site, independent of path lengths.

Design

• LocationExpander#expandLazily scans exactly like #expand, but records site spans and resolved artifacts instead of appending rendered paths. Validation (unknown labels, empty or multiple expansions for singular functions) still happens during analysis with the same error messages, by rendering paths transiently.
• StarlarkCustomCommandLine gains an EXPANDED_LOCATION_ARG_MARKER encoding. Rendering happens at preprocess time and mirrors LocationFunction (callable paths, sorted and deduplicated plural expansions, shell escaping), with exec paths going through the PathMapper — lazily expanded locations are thus compatible with --experimental_output_paths=strip.
• Literal segments and unknown functions render directly from the original string.
• The main repository's runfiles directory name (needed by $(rlocationpath) rendering) is a constant that only depends on the product, so it is recorded once when the ConfiguredRuleClassProvider is constructed rather than stored per expansion — it appears in neither the instance layout nor the retained encoding.
• Fingerprinting covers the original string, the site layout and the artifacts' unmapped exec paths; the effect of path mapping on the rendering is a pure function of these plus the output paths mode, which the consuming action fingerprints.

Notes for review

• Sending this as a draft to collect feedback on the API shape (lazy parameter on expand_location vs. a separate method) and on recording the runfiles directory in ConfiguredRuleClassProvider's constructor.
• Motivated by a Starlark library that implements the same idea with Args.add_joined/map_each tokens; the native form retains less (no literal substrings, no per-token tuples) and needs no library. Happy to share the detailed memory model and benchmark numbers.

🤖 Generated with Claude Code

https://claude.ai/code/session_012hbS4fiUT83VKyVTvxJkjf

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[meisterT]

cc @justinhorvitz

[fmeum]

I'm exploring doing this all in starlark over in https://github.com/fmeum/expanders.bzl. The native implementation would be more memory-efficient, but I'll first verify that the overall approach works.