commit 19fe9f087f1122c986a779b29b1c7832507868ea
author Googler <noreply@google.com> Tue Jan 05 11:17:00 2021 -0800
committer Copybara-Service <copybara-worker@google.com> Tue Jan 05 11:18:09 2021 -0800
tree 26ff1a4c7a91888842b31389ab8ca746544e8ae7
parent c8f4a146fbc6f1479a4d3f1ee77778f58133f2b7

Convert BuildType.SelectorList back to SelectorList in native.existing_rules

(Attempt two.)

This allows a round-trip like:

```
some_rule(
   ...
   deps = native.existing_rule(...)["deps"],
   ...
)
```

(native.existing_rule / native.existing_rules is disfavored, it's brittle and order-dependent. Prefer using a Starlark macro that creates the original target and related targets at the same time.)

When traversing the struct recursively, starlarkifyValue converts List into Tuple (though maybe StarlarkList would be more idiomatic) and Label into the corresponding str. So the select may not be exactly as input, but the meaning is preserved.

The logic for StarlarkValue is moved down because SelectorList is a StarlarkValue, so the more specific case needs to be handled first.

This change is not strictly backward-compatible because it changes the type and `repr` of these values, e.g. you can have something like:

```
if type(native.existing_rule(...)[...]) == "SelectorList":
  # Something broken that wasn't previously executed
```

Logic like this can be updated to use "select" instead of "SelectorList". (Or, if it was specifically working around the issue that SelectorList values can't be used as rule inputs, the workaround can be removed.)

RELNOTES[INC]: native.existing_rule now returns select values in a form that is accepted by rule instantiation. This is a breaking API change because there is some code that relies on the precise type returned, including brittle workarounds for this bug specifically and insufficiently flexible workarounds for other issues with the intersection of select and native.existing_rule.

PiperOrigin-RevId: 350180297