4 of 6 standards met
Summary This PR makes three Bazel-compatible improvements to Starlark built-in methods: 1. * โ Add optional and parameters, matching the Starlark spec and Python semantics. The substring is tested instead of the full string. 2. โ Same as above for . 3. โ Allow to be passed as a named keyword argument (e.g., ), not just positional. This matches Bazel's Java Starlark implementation and Python's . Motivation These changes are needed for Bazel compatibility. Real-world Bazel BUILD files and macros use these features extensively: Related Issues bazelbuild/starlark#56 โ The Starlark spec was updated to include / params for /, but never implemented them. Conformance test suite inconsistency* โ The bazelbuild/starlark conformance tests document this with: Implementation Details / Reuses the existing infrastructure (already used by , , , , ) to slice the string before testing. Supports both single string and tuple-of-strings prefix/suffix arguments. Removes from the parameter, allowing it to be passed as either positional or named. The parameter remains positional-only. Testing All 981 existing tests pass (828 lib + 153 doc) New tests added for each change: โ 7 assertions covering basic, negative indices, and tuple prefix โ 4 assertions covering basic, negative indices, and tuple suffix โ 3 assertions covering missing key, existing key, and fallback value
I recently submitted a few patches to the Bazel LSP (#100, #101, #103). However, this is intended to be merely a proof of concept and there are some larger changes that need to be made (e.g. adding tests, bzlmod support). There was some discussion on the future of this project in #51, and the conclusion seemed to be to eventually split it out into a separate project and maintained by people with more of a stake in Bazel, but only when the interface is stable enough. Is the interface stable enough to pull this out yet? If not, are you willing to accept contributions to this even though it is meant as a proof of concept, especially larger ones? If the interface isn't stable yet, does it make sense to keep the current PoC in this repo to verify changes to the interface, along with a more fleshed-out implementation in a separate repo?
Repository: facebook/starlark-rust. Description: A Rust implementation of the Starlark language Stars: 939, Forks: 86. Primary language: Rust. Languages: Rust (85%), Starlark (14.8%), Python (0.1%), TypeScript (0.1%), HTML (0.1%). License: Apache-2.0. Latest release: v0.13.0 (1y ago). Open PRs: 23, open issues: 30. Last activity: 1d ago. Community health: 75%. Top contributors: stepancheg, ndmitchell, JakobDegen, cjhopman, bobyangyf, krallin, perehonchuk, Nero5023, Will-MingLun-Li, jtbraun and others.
Last 12 weeks ยท 141 commits