fix(cargo_build_script): expand ${pwd} for execpaths and locations in build_script_env#4088
Merged
Merged
Conversation
slackito
reviewed
Jun 17, 2026
slackito
left a comment
slackito
left a comment
Collaborator
There was a problem hiding this comment.
Could you please add tests for your fix? There's a location expansion test at //test/unit/location_expansion:location_expansion_test_suite but it only covers execpath, and it does so in the rustc_flags of a rust_library target. I think you could add testing for the plural forms there.
You might also want to add another test for cargo_build_script to check that your intended use case is covered too.
…n build_script_env
Singular $(execpath ...) and $(location ...) were already prefixed with
\${pwd}/ so build_script_runner could resolve them to absolute paths at run
time. The plural forms $(execpaths ...) and $(locations ...) were silently
omitted from this handling, leaving their paths as execroot-relative.
For plural forms each macro is expanded individually (via ctx.expand_location)
and every resulting space-separated path is prefixed with \${pwd}/.
Tests: one rust_library covering all four macro forms in rustc_flags (each
referencing a distinct generated file), and a cargo_build_script test
verifying $(execpaths ...) in build_script_env is resolved to an absolute
path at run time.
basvandijk
added a commit
to dfinity/ic
that referenced
this pull request
Jul 2, 2026
rules_rust 0.71.x (bazelbuild/rules_rust#4088) started prefixing every path expanded from the plural $(locations ...) / $(execpaths ...) forms with the ${pwd} substitution token, like it already did for the singular forms. That token is only substituted by the process wrapper during build actions; nothing substitutes it in a test's runtime environment (RunEnvironmentInfo), so tests saw literal '${pwd}/rs/...' paths and failed to open them. Use $(rootpaths ...) which rules_rust deliberately leaves unmodified for runtime use and which expands to the same runfiles-relative paths as $(locations ...) did before 0.71.x for these source files. Fixes: //rs/dogecoin/ckdoge/minter:unit_tests //rs/nns/governance:governance_integration_test //rs/nns/governance:merge_neurons_test //rs/nns/integration_tests:integration_tests_src/governance_neurons //rs/tla_instrumentation:args_test //rs/tla_instrumentation:multiple_calls_test //rs/tla_instrumentation:structs_test
pull Bot
pushed a commit
to mikeyhodl/ic
that referenced
this pull request
Jul 2, 2026
Upgrades `rules_rust` from 0.69.0 to 0.71.3. - Drops `bazel/rules_rust_package_alias.patch`: the `package_alias` attribute is upstreamed in 0.71.3 ([rules_rust#3742](bazelbuild/rules_rust#3742)). - Regenerates `bazel/rules_rust_strip_level.patch` for 0.71.3: still needed because the native `rust.toolchain` `strip_level` tag attribute is a flat `string_dict` that cannot express the per-compilation-mode config (and is looked up by target triple downstream) ([rules_rust#3730](bazelbuild/rules_rust#3730)). - Adds `bazel/rules_rust_dep_env.patch`: rules_rust 0.71.x redacts the producer's out_dir to a generic `${out_dir}` token in dep env files, but those files are consumed by *downstream* crates' build scripts whose `--out-dir` differs, leaving the token unresolved (e.g. `libssh2-sys` failing to find `zlib.h` from `libz-sys`'s `DEP_Z_INCLUDE`). - Updates `bazel/hermetic_cc_toolchain_strip.patch`: the zig-wrapper now invokes `strip` via an absolute path (`/usr/bin/strip` or `/bin/strip`, failing with a clear error if neither exists), because rules_rust 0.71.x runs the wrapper at rustdoc doc-test time with a cleared environment (no `PATH`), where a bare `strip` fails to resolve. - Repins the Cargo Bazel lockfile (checksum-only change). - Switches test `env` attributes from `$(locations ...)` to `$(rootpaths ...)`: since [rules_rust#4088](bazelbuild/rules_rust#4088) (0.71.x) the plural `$(locations ...)`/`$(execpaths ...)` forms are `${pwd}`-prefixed like the singular forms; that token is only substituted during build actions, so test runtime envs saw literal `${pwd}/...` paths. `$(rootpaths ...)` is deliberately left unmodified for runtime use. --------- Co-authored-by: IDX GitHub Automation <infra+github-automation@dfinity.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Singular
$(execpath ...)and$(location ...)were already prefixed with${pwd}/so build_script_runner could resolve them to absolute paths at run time. The plural forms$(execpaths ...)and$(locations ...)were silently omitted from this handling, leaving their paths as execroot-relative.For plural forms each macro is expanded individually (via ctx.expand_location) and every resulting space-separated path is prefixed with
${pwd}/.