Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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
- Loading branch information