Tags: facebook/buck2

Write toolchain compiler argsfiles once per toolchain, not per target

Summary:
Second attempt at landing D117561703. Some toolchains embed actual artifact paths, not just compiler flags, so passing around JUST the argsfile artifact fails to include the referenced artifacts in the subsequent compile actions that use them. Action's `associated_artifacts` can get easily lost, so it's safer to produce and return the argsfile as a `cmd_args()` with the input artifacts as `hidden=` on them. D117861848 fixes that for us.

----

Original Phabricator Diff: D117561703

The original landing broke `@//arvr/mode/platform010/code-coverage` builds of zbuild targets (e.g. `fbsource//arvr/firmware/wearables/libs/interconnect/tests/sabaton_emulator:interconnectMcuMcuQemuEmuTest`), which triggered the revert. Root cause: this diff is the first to populate `compiler_info.argsfile` for toolchains whose flags embed artifact paths (the `gcc-arm-none-eabi` toolchain passes `-imacros $(location fbsource//third-party/zephyr/zephyr_rtos:zephyr_stdint.h)`), and zbuild's `module_static_library.bzl` consumed the field as a bare artifact — dropping the referenced artifacts from the compile action's inputs, so `zephyr_stdint.h` was never materialized. The previous diff fixes that structurally: the fields are now input-carrying `cmd_args` built with `argsfile_with_artifacts()`, which this diff uses to construct them.

This diff also moves the C++20-modules precompile filtering up to toolchain analysis. Now that the toolchain writes its argsfiles, the per-target filter anon target is pure overhead — and an active hazard, since its promise artifact strips the pairing between the file and the artifacts its flags reference. `mk_toolchain_precompile_argsfile` runs `filter_argsfile` over the toolchain argsfile once per toolchain (declared lazily; it only executes when a modules precompile demands it) and stores the result as a new `argsfile_precompile` field on the cxx compiler info, paired with its flags at the one site where they live. The fbcode modeless wrapper regenerates `argsfile_precompile` from its own mode flags for the same reason it regenerates `argsfile`. The anon-target filter remains only as a fallback for toolchains that don't provide argsfiles.

`fbsource_universal_cxx_toolchain` appends `extra_cany_compiler_flags` to five compiler infos while copying every other field from the base — including, once this diff lands, the base's argsfiles, which would no longer match the flags and would silently drop the extras from compile lines (compiles prefer the argsfile). It now regenerates the argsfiles when extras are present, and passes the base infos through untouched when they aren't (today's only instantiation passes `extra_cany_compiler_flags = []`).

Reviewed By: akrieger

Differential Revision: D117861849

fbshipit-source-id: 34b10782b7c36b8930e0a1749fe73891c5b7093e

Exclude the LLVM lit macros from buck2's prelude ci_hints

Summary:
Three `ci_hint` glob lists hint on all of `tools/build_defs/**`, which
covers `tools/build_defs/llvm` -- the LLVM build macros. None of the
hinted tests use them, so editing an LLVM macro pulls in every Apple rule
test, every non-isolated buck2 e2e test, and the sample build jobs.
Exclude to avoid unnecessary broad CI jobs and improve the chances of
relevant ones getting run.

Reviewed By: bcardosolopes

Differential Revision: D117884846

fbshipit-source-id: 267bbe2d041bf93dedd578a3eaf467852e640a33

No-op generic typetag registration on wasm

Summary:
The starlark-rust OSS CI wasm job (`ci_oss_wasmtime.sh`, mirrored internally by `fbcode//buck2/scripts/oss:starlark-rust-oss`) builds `starlark` for `wasm32-wasip1`. Since the generic typetag auto-registration landed (`matchers.rs` / `function.rs` monomorphization constructors, 2026-08-13), that build dies in `__pagable_emit_generic_typetag_registration!`'s catch-all arm:

```
error: generic pagable typetag registration supports only 64-bit Linux/macOS and x86_64/aarch64 Windows
  --> starlark/src/values/typing/type_compiled/matchers.rs:91:1
```

Wasm cannot use the constructor-record approach: `core::arch::asm!` is unsupported on wasm targets, and a wasm image has no loader-run constructor section for a per-monomorphization record anyway. Add a wasm arm that emits no registration — deserializing a generic typetag on wasm then fails with the registry's existing "Unknown type tag" error instead of failing the whole build at compile time. Concrete (`inventory`-based) registrations are unaffected.

Reviewed By: jtbraun

Differential Revision: D116564107

fbshipit-source-id: 826aec636b17a96f18afcf9101f9667c2ddec662

Layer `.bucksettings.local.toml` in home dir over repo root settings

Summary:
Parses `.bucksettings.local.toml` from home dir. Home-local settings are recursively merged over the repo-root `.bucksettings.toml`. The pipeline is now discover settings files -> parse into tables -> merge into one table -> deserialize into `BuckSettingsData`.

Adds unit coverage for layered parsing and an e2e test verifying that a home-local value overrides the repo value.

Reviewed By: Nero5023

Differential Revision: D113876491

fbshipit-source-id: d04ffa478d03070b0e4a6619140b7fc9e5dc67a5

Pin macOS OSS CI to macos-14 to unbreak Build and test

Summary:
The `macos-build-and-test` job in the OSS "Build and test" workflow (and the sibling `macos-build-examples` job in "Build and Examples") regressed again after GitHub's `macos-latest` label advanced to the `macos-15` runner image. On `macos-15`, `xcode-version: latest-stable` selects an Xcode/SDK that mis-targets the deployment SDK and breaks the `cargo build` step (see actions/runner-images#12758).

This matches the reported "recently regressed, previously recovered" pattern: switching the pin to `latest-stable` in `Use latest stable Xcode in OSS CI` briefly recovered the job while `macos-latest` still resolved to `macos-14`, then it re-broke once the label rolled forward to `macos-15`.

Pin `runs-on: macos-14` in both `build-and-test.yml` and `build-and-examples.yml`, where `latest-stable` resolves to a known-good Xcode 16.x. This is the documented remedy and is trivially reversible once the `macos-15` image is fixed upstream.

This is a GitHub-hosted-runner-image regression, not a buck2 code bug — internal macOS builds use Meta's own toolchains and stayed green, which is why it was not caught by internal signal.

___

Differential Revision: D111806260

fbshipit-source-id: d827c7eb21750faff519ece8be81a81a6f16eaa6

windows-sys: enable WindowsFilteringPlatform + Authorization

Summary:
Enable the WFP (Windows Filtering Platform), Security Authorization, and System
Rpc features on the `windows-sys` crate so the Windows sandbox
(sandbox-runtime/windows-native-sandbox-rs) can install network-isolation
filters. Win32_Networking_WinSock comes in transitively.

Generated by `reindeer buckify` (third-party/rust/Cargo.toml + vendor/windows-sys/BUCK),
then `arc autocargo` to sync the mirrored windows-sys feature set into the
autocargo-enrolled consumers (arvr/apps/hzdb, fbcode/buck2,
fbcode/scm/dotslash/oss/windows_shim).

Reviewed By: dtolnay

Differential Revision: D109989460

fbshipit-source-id: 85fa0963c6a90a93f729afb7f35aca7f2ec9adb8

fix index overflow in enumerate with large start

Summary:
**Index overflow in `enumerate` with a large start**

The per-element index is built as `k as i32 + start`, so when the caller passes a `start` near `i32::MAX` the addition overflows on the first elements rather than at some unreachable list length. Cause is doing the arithmetic in `i32` even though Starlark integers are arbitrary precision, so the correct result does not fit. Fix widens the running index to `i64` before adding the offset.

`enumerate(['a', 'b'], 2147483647)` panics with "attempt to add with overflow" in debug and wraps to a negative index in release; it should yield `[(2147483647, 'a'), (2147483648, 'b')]`. Added a regression test alongside the existing builtin tests.

Should be safe as the index can no longer exceed `i64` for any in-memory iterable, though a reviewer may prefer matching whatever width the range work settled on.

X-link: facebook/starlark-rust#203

Reviewed By: JakobDegen

Differential Revision: D108556073

fbshipit-source-id: 2d2b80304aba92dc806f4338e8227c143820fc69

Avoid heap allocations in dep-file digest comparisons

Summary:
`check_remote_dep_file_entry` was calling `.to_vec()` on digest byte
slices just to compare them against `Vec<u8>` fields from the proto.
Compare `&[u8]` slices directly instead, eliminating 4 unnecessary heap
allocations per remote dep-file cache check.

Reviewed By: scottcao

Differential Revision: D106082425

fbshipit-source-id: e1d81b983a61bff494f9b5917afbaec815192d2d

Fix broken @oss-disable markers that break OSS builds

Summary:
Several prelude files had `# oss-disable` only on the closing line of multi-line statements. Codesync strips marked lines individually, so this left dangling syntax (unclosed `load(` calls, empty `if False:` bodies) that caused Starlark parse errors in OSS builds.

Fixes:
- Multi-line `load()` statements: mark every line with `# oss-disable`, not just the closing paren.
- `if`/`else` blocks where the `if` body is fully disabled: add `# oss-enable: pass` so the `if False:` block has a valid body after stripping.

Files: `android_binary_native_library_rules.bzl`, `apple_binary.bzl`, `apple_library.bzl`, `apple_error_handler.bzl`.

This fixes the `buck2-oss-docs` CI test which has been disabled due to these parse errors.

Reviewed By: JakobDegen

Differential Revision: D105501080

fbshipit-source-id: f99170c91a668851632a2fdafb81247798e1404a

Fix rustdoc private_intra_doc_links issue in pagable storage trait

Summary:
The issue https://github.com/facebook/buck2/actions/runs/25183757994/job/73835505180 shows

```
ERROR: Documentation warning:
warning: public documentation for `store_data` links to private item `PagableData::compute_key`
  --> pagable/src/storage/traits.rs:76:11
   |
76 |     /// [`PagableData::compute_key`]; if the same data is stored twice the second
   |           ^^^^^^^^^^^^^^^^^^^^^^^^ this item is private
   |
   = note: this link will resolve properly if you pass `--document-private-items`
   = note: `#[warn(rustdoc::private_intra_doc_links)]` on by default
```

The docstring for `PagableStorage::store_data` used an intra-doc link to `PagableData::compute_key`, but `compute_key` is `pub(crate)`.

So remove `[]`,

___

overriding_review_checks_triggers_an_audit_and_retroactive_review
Oncall Short Name: build_infra

Differential Revision: D103304382

fbshipit-source-id: 04c8e3e92d70d2c2a19f3cd5641b5cbc6f496c8a