Input discovery for map_directory actions #31849

Description of the feature request

Allow template_ctx.run actions to retain an execution-discovered subset of a declared input universe. Proposed paired parameters are discovery_inputs (individual candidate Files) and used_inputs_list (an output listing the candidates actually used). Inputs and tools outside the candidate set remain mandatory.

Which category does this issue belong to?

Rules API, Starlark Integration, Core

What underlying problem are you trying to solve?

A native compiler scan created from an execution-time manifest needs access to a broad source/generated namespace. Plain SpawnAction template children keep every declared input as an invalidating dependency, so unrelated edits rerun scans even after the compiler has identified its actual dependencies. Merely splitting a batch into individual scans does not change those keys.

Ordinary ctx.actions.run has post-execution unused_inputs_list support. The motivating source tree has roughly 100,000 candidates; emitting its unused complement for thousands of scans would be substantial repeated output. The proposed used set would reuse the existing EnhancedStarlarkAction discovery/cache owner, with fixed mandatory inputs and membership fingerprints to catch added or shadowing files. It would not add cold-client cache guarantees or replace native compiler lookup semantics.

Environment

macOS ARM64 client with declared Linux remote execution. API investigation covers Bazel 9.3 and current master e91365e1209ee6b9e7ed3fe0b3ebd5cd1a965d42. A proof-of-concept binary was built from the canonical //src:bazel target; no consumer version pin has changed.

Related work and remaining evidence

#29193 discusses pre-execution unused-list processing and is distinct from this post-execution proposal. Proposal #422 contains the draft design, its evidence, and unresolved costs. It has no maintainer approval; the announcement/discussion step has not been performed.

Tests cover warm-cache invalidation, source and generated children, membership and tool changes, path mapping, and malformed reports. A real Linux remote-execution fixture has passed with three separate scanner children followed by compiler/backend/export actions under top-level-only downloads. Unchanged and unrelated edits ran no scans or compiler actions; source, header, and embedded-binary mutations each selected only their affected scanner and compiler chain. Full-scale traversal costs remain unmeasured. The old consumer counted batch scans, so it does not establish a per-object performance baseline.

Prepared by OpenAI Codex on behalf of @tamird.