[7.2.0] Automatically map paths in Args#map_each
#22221
Milestone
Comments
|
Cherry-pick was attempted but there were merge conflicts in the following file(s). Please resolve manually.
cc: @bazelbuild/triage |
cc: @fmeum @aranguyen @lberki |
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
May 10, 2024
When path mapping is enabled, `File` objects accessed in a user-supplied callback passed to `Args#map_each` automatically have their paths mapped. Automatic rewriting is preferable to e.g. passing a rewriter object into the callback: All paths emitted into command lines must be rewritten with path mapping as inputs and outputs are staged at the mapped locations, so the user would need to manually map all paths - there is no choice. As an added benefit, the automatic rewriting ensures that existing rules relying on `map_each` do not need to be modified to use path mapping. This is a reland of 955b31e, which got rolled back due to a 7% CPU time increase on a benchmark caused by frequent comparisons of equal but not reference equal `StarlarkSemantics` used as keys in the `StarlarkClassDescriptor` cache in `CallUtils`. Instead of overriding `equals` and `hashCode` for `PathMapper`, this change subclasses `StarlarkSemantics` to provide a different, reference equal instance as the cache key. This is safe since the value associated with the `path_mapper` key does not affect the availability of any Starlark field or method, just the behavior of their implementations. Work towards bazelbuild#6526 Closes bazelbuild#21952. PiperOrigin-RevId: 629546010 Change-Id: Ib21fa2371a28a02f0c868523b410c5a40c2c6c82 Closes bazelbuild#22221
|
Cherry-picked in #22322 |
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
May 10, 2024
When path mapping is enabled, `File` objects accessed in a user-supplied callback passed to `Args#map_each` automatically have their paths mapped. Automatic rewriting is preferable to e.g. passing a rewriter object into the callback: All paths emitted into command lines must be rewritten with path mapping as inputs and outputs are staged at the mapped locations, so the user would need to manually map all paths - there is no choice. As an added benefit, the automatic rewriting ensures that existing rules relying on `map_each` do not need to be modified to use path mapping. This is a reland of 955b31e, which got rolled back due to a 7% CPU time increase on a benchmark caused by frequent comparisons of equal but not reference equal `StarlarkSemantics` used as keys in the `StarlarkClassDescriptor` cache in `CallUtils`. Instead of overriding `equals` and `hashCode` for `PathMapper`, this change subclasses `StarlarkSemantics` to provide a different, reference equal instance as the cache key. This is safe since the value associated with the `path_mapper` key does not affect the availability of any Starlark field or method, just the behavior of their implementations. Work towards bazelbuild#6526 Closes bazelbuild#21952. PiperOrigin-RevId: 629546010 Change-Id: Ib21fa2371a28a02f0c868523b410c5a40c2c6c82 Closes bazelbuild#22221
github-merge-queue bot
pushed a commit
that referenced
this issue
May 10, 2024
When path mapping is enabled, `File` objects accessed in a user-supplied callback passed to `Args#map_each` automatically have their paths mapped. Automatic rewriting is preferable to e.g. passing a rewriter object into the callback: All paths emitted into command lines must be rewritten with path mapping as inputs and outputs are staged at the mapped locations, so the user would need to manually map all paths - there is no choice. As an added benefit, the automatic rewriting ensures that existing rules relying on `map_each` do not need to be modified to use path mapping. This is a reland of 955b31e, which got rolled back due to a 7% CPU time increase on a benchmark caused by frequent comparisons of equal but not reference equal `StarlarkSemantics` used as keys in the `StarlarkClassDescriptor` cache in `CallUtils`. Instead of overriding `equals` and `hashCode` for `PathMapper`, this change subclasses `StarlarkSemantics` to provide a different, reference equal instance as the cache key. This is safe since the value associated with the `path_mapper` key does not affect the availability of any Starlark field or method, just the behavior of their implementations. Work towards #6526 Closes #21952. PiperOrigin-RevId: 629546010 Change-Id: Ib21fa2371a28a02f0c868523b410c5a40c2c6c82 Closes #22221
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Forked from #21952
The text was updated successfully, but these errors were encountered: