Allow dict(), **, and | to operate on non-dict mappings

[brandjon]

Currently, dict(v) allows v to be either an iterable of key-value pairs, or another dict object whose entries get included into the new dict. We should additionally allow v to be a non-dict mapping. In Bazel an example of such a type would be OutputGroupInfo.

See bazelbuild/starlark#198 for the corresponding spec change.

Implementation wise, following the precedent of StarlarkIterable vs Iterable, we'd probably want to create a marker interface StarlarkMapping, rather than using the standard Java Map interface. StarlarkMapping would extend StarlarkIterable and StarlarkIndexable. Using a marker interface as opposed to Map gives more control to the implementor; in particular, it lets us say that OutputGroupInfo is a mapping without having to implement an extra Java API we don't want it to have. Conversely, it also avoids changing the Starlark semantics of a type whenever its class gains or loses the Map interface.

OutputGroupInfo would be made to implement StarlarkMapping instead of StarlarkIterable and StarlarkIndexable (which it would still inherit indirectly). In contrast, TransitiveInfoCollection would continue to implement StarlarkIndexable without StarlarkIterable, since it does not support enumeration of providers. Other types, e.g. toolchain contexts, may or may not choose to be classified as a mapping.

Implementing StarlarkMapping wouldn't obligate you to support, e.g., efficient enumeration of keys via a view object. It's simply the join of iterable and indexable.

This issue came up in the discussion of Improving native.existing_rules, where it was pointed out that migrating the return value from a dict object to a dict-like view would require any users who wanted to copy the result to do dict(view.items()) rather than simply dict(view). @tetromino fyi.

[mahmoudimus]

Hi @brandjon - happy to take a stab at a PR to support this if you’re up for it.

[tetromino]

Another wart we'd want to fix here is ** operator: currently, calls like func(x, y, **kwargs) require kwargs to be a dict, but they ought to support any mapping.

---

Note that after taking a quick stab at implementing StarlarkMapping using StarlarkNativeModule.DictLikeView as a model, I'm now leaning to having StarlarkMapping extend Map. Too much friction with Dict otherwise.

[tetromino]

... and another wart: #14540 will add the Python 3.9 style union operator for dicts, which the dict-like views will not support.

Thus, I think we need to tackle problem sooner rather than later.

[tetromino]

I believe this should be fixed by cf99f84 + dfa9c62 + 16b82af