incompatible_disallow_hashing_frozen_mutables: freezing a list should not make it hashable

[laurentlb]

Reported by @alandonovan

$ cat test/inc.bzl 
a_list = []

$ cat test/BUILD 
load(":inc.bzl", "a_list")

print(a_list)
print({a_list: 1}) # ok
print({[]: 1}) # error

$ bazel query test:*
DEBUG: test/BUILD:3:1: [].
DEBUG: test/BUILD:4:1: {[]: 1}.
ERROR: test/BUILD:5:7: Traceback (most recent call last):
        File "test/BUILD", line 5
                print({[]: 1})
        File "test/BUILD", line 5, in print
                {[]: 1}
unhashable type: 'list'.

Lists shouldn't be hashable, even if they are frozen.
For the user, a possible fix is to convert the list to a tuple.

[alandonovan]

Besides the slightly strange observation that freezing a value both removes some operations (mutation) while adding others (hashability), a reason not to allow this is that a mutable value may contain itself, such as a list that contains itself as an element. Without major changes to the implementation of hashing, attempting to hash such a value would get stuck or crash.

Reliance on this feature was already removed from all of Google's loading-phase Starlark with very modest effort. I imagine the challenge will be the analysis phase, where it's common for users to insert struct/provider instances into dicts or depsets. Those structs/providers would have to use tuples instead of lists.

[laurentlb]

cc @Quarz0

[dslomov]

What is the extent of the breakage? I assume there is no migration tooling that we can possibly create.

[laurentlb]

Breakages are expected to be rare. I've built large projects inside Google without finding any issue (although Alan says he fixed some in the loading phase).