You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix javacopts semantics broken by storing them as depsets
The final javacopts passed to `JavaBuilder`/`javac` is computed (in `java_common.compile`) by concatenating the following sets of options (in order):
1. The `javacopts` attribute on `java_toolchain`
2. The options provided with `--javacopt` on the commandline
3. The matching `compatible_javacopts` attribute on `java_toolchain`
4. The matching options from `java_toolchain.package_config`
5. The `javacopts` attribute on the `java_*` rule
We already de-tokenize each of these sets into a single space-separated string before adding them to a `depset` (not doing so would mean `['-source', '8', '-target', '8', '-Xmx1G']` would result in getting back `['-source', '8', '-target', '-Xmx1G']` from the depset).
In most cases, this de-tokenization is enough to ensure we get back the same set of options as we would if we stored them as a list. However, in the rare case that any of the above sets is *exactly* identical to another, it gets de-duped upon flattening.
Since the right-most option should win, this change makes it so, that after de-duping, the right-most occurrence is preserved. A depset always performs left-to-right traversal, so all we need to do is add the above 5 sets of options in reverse order, and then reverse once more after flattening.
PiperOrigin-RevId: 573895869
Change-Id: Id4758597e6d93fe5c71856a742915cafc1287a68
0 commit comments