4 of 6 standards met
The last starlark-rs release was in 2024 by @ndmitchell. But since then a bunch of internals have changed like the heap branding work done by @JakobDegen so it'd be nice if non-fbsource users could update to that work. It'd also be nice if these PRs across both buck2 and starlark-rs could get in: https://github.com/facebook/buck2/pull/1148 https://github.com/facebook/buck2/pull/1141 https://github.com/facebook/starlark-rust/pull/158 https://github.com/facebook/starlark-rust/pull/146 cc @Nero5023 and @JakobDegen since both of you recently had diffs land in starlark. Thanks.
Add a configurable execution_concurrency_limit to buck2_re_client that limits the number of remote executions that can happen concurrently. I'm open to any sort of debate about what the default should be. I randomly picked 400. fbcode likes to use 4000. Bazel likes to use 400. It looks like the fbcode client probably internally already has a semaphore, but this would put a semaphore on the outside. If you guys think it would be better for me to move the semaphore into the OSS client, let me know.
Repository: facebook/buck2. Description: Build system, successor to Buck Stars: 4264, Forks: 330. Primary language: Rust. Languages: Rust (54.2%), Starlark (21%), Java (12.9%), Python (7.4%), Kotlin (2.3%). License: Apache-2.0. Homepage: https://buck2.build/ Open PRs: 82, open issues: 282. Last activity: 14h ago. Community health: 75%. Top contributors: stepancheg, JakobDegen, krallin, ndmitchell, cjhopman, iguridi, Nero5023, bobyangyf, wendy728, christolliday and others.
Last 12 weeks · 1341 commits
A change that we've been keeping in our prelude fork, not sure if you want to adopt it into upstream as-is, let me know if you have suggestions for changes or a better implementation! This change implements support for running and targets under exposed as a sub-target. Under the hood this makes two changes: 1. we add the sub-target in that will rust call instead of with the explicit miri sysroot given to the toolchain as described here. This is the easy part. 2. we also introduce a new that will be propagated through the existing dependency resolution and compilation logic and be superficially treated as a regular "link" type compilation but allows us to switch out the compiler to a wrapper script (similar to how the clippy wrapper works). This will ensure the rlibs have the right structure and will be understood when we pass them to the "interpretation phase" of miri. Note that as a QOL feature when injecting the sub-target in we switch on the presence of to - instead of a provider - inject an so that users can just run instead of .
Running in debug mode would panic as clap has a debug assert to check for duplicate argument IDs. It is my understanding that duplicating argument IDs can cause bugs in release mode, even if they are under different subcommands.