Tags: meta/buck2

fs_util: Recover from permission errors when removing buck-out paths (#…

…1352)

Summary:
When building OS images with buck2, read-only directories show up in
buck-out because various distributions give their top level directories
and directories in /etc restrictive permissions. Removing such outputs
fails with EACCES, since unlinking a directory entry requires write and
execute permission on the containing directory.

Mirror the existing Windows readonly fallback on Unix:

- `remove_dir_all()` now adds owner read/write/execute permission on
  every directory in the tree and retries when it hits a permission
  error. It only ever modifies directories inside the tree being
  removed; in particular it never touches the parent directory of the
  path passed in. Each directory is opened relative to its parent
  without following symlinks and its mode is changed through that
  descriptor, so a symlink is never followed and paths longer than
  `PATH_MAX` work.

- New `remove_file_harder()` and `remove_dir_harder()` add owner
  read/write/execute permission on the containing directory and retry.
  Since that changes the permissions of that directory, they are kept
  separate from `remove_file()` and `remove_dir()` and only used where
  the containing directory is being removed too: below the top level of
  `buck2 clean`. The buck-out root, which `buck2 clean` keeps, is left
  alone.

- `buck2 clean` falls back to `remove_dir_all()` for a directory it
  could not list (e.g. mode 000), which would otherwise never empty.

Since `clean --stale` and the idle scratch sweep delete through
`remove_all()`, they now delete untracked entries whose contents the scan
could not read, instead of skipping them. Entries that stay undeletable
(e.g. owned by another user) are still counted and skipped.

Pull Request resolved: #1352

Test Plan:
```
buck2 test fbcode//buck2/app/buck2_fs:buck2_fs-unittest fbcode//buck2/app/buck2_client:buck2_client-unittest fbcode//buck2/app/buck2_execute:buck2_execute-unittest fbcode//buck2/app/buck2_execute_impl:buck2_execute_impl-unittest fbcode//buck2/tests/core/clean/... fbcode//buck2/tests/core/materializer/... fbcode//buck2/tests/core/executor:test_output_cleanup
```
737 passed. New unit tests remove a read-only tree, a tree with a symlink to a read-only directory (whose mode must not change), a read-only tree deeper than `PATH_MAX`, an unlistable directory in `buck2 clean`, and check that neither the parent of `remove_dir_all()` nor the `buck2 clean` root has its permissions changed.

`buck2 build fbcode//mode/mac-arm64` and `fbcode//mode/win` of `buck2_fs` and `buck2_client` succeed.

Reviewed By: Nero5023

Differential Revision: D110600034

Pulled By: 8Keep

fbshipit-source-id: 2c06ff27e33087234ede417c4a59a66b075b92a7

invalidation: Drop the derived ordering on Version

Summary:
Only the invalidation path merge compared versions, and it did so with the
derived lexicographic order, which happens to be right for two versions of
one chain: branch ids are minted in creation order and a branch is younger
than the one it was forked from. No behavior change here; the comparison is
the same, under a name that says when it is meaningful, and the guarantee it
rests on is written down on `BranchId`, which `CoreState::branches` already
relied on for its parents-before-children order.

___

landed-with-radar-review

Differential Revision: D128864614

fbshipit-source-id: 95026364db3b164add47b5644d682a1cd6f24550

Document exec marker preservation

Summary:
Transition authors can return a replacement `PlatformInfo`, but the effective exec configuration also retains the marker owned by Buck2. The existing guides did not explain this exception, leaving it unclear what happens when a transition omits the marker or sets it to `false`.

Document the contract in `ExecutionPlatformRegistrationInfo.exec_marker_constraint` and the execution platform and transition guides: constructors and single/split transitions restore a missing marker, while explicitly returning a different value is an error. Transition authors can omit the marker and let Buck2 preserve it. Manually supplying the same constraint on an ordinary target does not enable restoration or conflict rejection. Clarify the registration's fallback scope and the marker's presence during idempotence validation. Link the conceptual transition guide to this behavior, including its effect on otherwise empty outputs.

Reviewed By: NavidQar

Differential Revision: D124812251

fbshipit-source-id: 778d5905f00f813e64ddc71af9b7844455a5cc7d

Export generated sources only for full library builds

Summary: Source ABI and source-only ABI CD actions return generated-source trees that have no consumers, causing unnecessary RE directory-metadata downloads on cache hits. Make the annotation output paths optional in the protocol and keep omitted paths inside BUCK_SCRATCH_PATH. The rules declare generated-source directory outputs only for full library compilation, preserving their existing providers and subtargets.

Reviewed By: siaojiecai

Differential Revision: D122335997

fbshipit-source-id: 3625e69c0fc6e4e5d7ad47fece1843d1c3fa5722

Update flate2 from 1.1.9 to 1.1.10 (second attempt)

Summary: The WhatsApp crash that caused the revert in {D120009380} is resolved by {D120014105}.

Reviewed By: capickett

Differential Revision: D120031636

fbshipit-source-id: 60fe614f9b5661e3efbb189380692c841d0bd61a

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