--experimental_output_paths=strip cannot be disabled for built-in mnemonics #21092
Assignees
Labels
P2
We'll consider working on this in future. (Assignee optional)
team-Configurability
platforms, toolchains, cquery, select(), config transitions
type: bug
Comments
|
Dupe of #21091? |
|
@iancha1992 It's not a dupe, these are two separate bugs affecting the same feature. |
fmeum
added
team-Configurability
|
I submitted #21093 to fix this. |
iancha1992
pushed a commit
to iancha1992/bazel
that referenced
this issue
Feb 21, 2024
By removing Java rules from the hard-coded mnemonics allowlist for path mapping, users can rely on `--modify_execution_info` to selectively disable path mapping for them just like for Starlark actions. This requires fixing two minor inconsistencies in how execution info is populated for Java actions: * In `JavaCompilationHelper`, `buildKeepingLast` is used instead of `buildOrThrow` to prevent a crash when a target sets `supports-path-mapping` via `tags`. * In `JavaHeaderCompileAction`, `--experimental_inmemory_jdeps_files` no longer causes all other execution info to be lost. Fixes bazelbuild#21092 Closes bazelbuild#21093. PiperOrigin-RevId: 609064092 Change-Id: I6803e34a6861f19d185542e707b00029ee018a0a
github-merge-queue bot
pushed a commit
that referenced
this issue
Feb 21, 2024
…ath mapping (#21461) By removing Java rules from the hard-coded mnemonics allowlist for path mapping, users can rely on `--modify_execution_info` to selectively disable path mapping for them just like for Starlark actions. This requires fixing two minor inconsistencies in how execution info is populated for Java actions: * In `JavaCompilationHelper`, `buildKeepingLast` is used instead of `buildOrThrow` to prevent a crash when a target sets `supports-path-mapping` via `tags`. * In `JavaHeaderCompileAction`, `--experimental_inmemory_jdeps_files` no longer causes all other execution info to be lost. Fixes #21092 Closes #21093. Commit f8337c7 PiperOrigin-RevId: 609064092 Change-Id: I6803e34a6861f19d185542e707b00029ee018a0a Co-authored-by: Fabian Meumertzheim <[email protected]>
|
A fix for this issue has been included in Bazel 7.1.0 RC1. Please test out the release candidate and report any issues as soon as possible. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the feature request:
When this flag is enabled, it doesn't respect the execution requirements for a hardcoded list of
SUPPORTED_MNEMONICS, meaning they cannot be disabled by the end user if they are misbehaving.Which category does this issue belong to?
Java Rules
What underlying problem are you trying to solve with this feature?
Our custom starlark actions work great with this flag, so we would like to use it for those, but the built-in rules are misbehaving (see #21091)
The text was updated successfully, but these errors were encountered: