commit 03c6fbae8bc1a9437c00b95b11ec7ad236a831fe
author adonovan <adonovan@google.com> Thu Apr 09 12:10:06 2020 -0700
committer Copybara-Service <copybara-worker@google.com> Thu Apr 09 12:11:26 2020 -0700
tree 1e0c9974783b4060d18a3d92a8ab8801fa218eb2
parent e29829165e15645f578b6dea61b04c900ea54a8b

bazel syntax: avoid materializing Locations for iterator check

Mutable iterable values (such as lists) are temporarily rendered
shallowly immutable when one or more for-loops are actively iterating
over them. Prior to this change, the value's Mutability would maintain
a hash table mapping objects to a list of active for-loop locations.

This meant that every for-loop caused memory allocation, and required
a Location for the loop. In a future change, I plan to avoid
materializing Locations during parsing, which will allow us to improve
the fidelity of position information recorded in the syntax tree, and
also reduce the memory required by syntax trees. However, it does mean
that Locations will not be materialized except in case of error.

This change replaces the lists of locations in the hash table by a
counter. Also, it adds a method to the Freezable interface that
permits value classes to implement their own intrusive counter.
The two most important mutable iterable types, StarlarkList and Dict,
now do this.

The error message for mutation of an actively iterated value no
longer prints the location of the for-loop, but it is usually obvious
from the stack trace.

Also:
- delete MutabilityException; use a plain EvalException.
- EvalUtils.lock,unlock removed from public API.
- Mutability: encode isFrozen boolean using iterators==null.
- Mutability.checkMutable inlined. The inconsistency check is
  removed---it was recently unreachable by construction.
- MutabilityTest: delete tests of obsolete functions.
- Freezable.checkMutable() renamed to Starlark.checkMutable(Freezable).
  No need for it to be a mix-in any more.
- Report type of frozen mutable value in failed update exceptions.
PiperOrigin-RevId: 305732656