tree 342ce0dfd00d2d43d20a0b22b68903ce81f05004
parent e68ae7206dd3ccc98c0b69ff4c54cd511a663a46
author Bob Nystrom <rnystrom@google.com> 1706824686 -0800
committer GitHub <noreply@github.com> 1706824686 -0800
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJlvBPuCRC1aQ7uu5UhlAAAxOcQAIQMahjri9LANy55F+AzinLJ
 xFaarhTXl/mCOPRmOLOMTzOJxU2uNEsvHuawX7/aZ2ylOa0Wrn3ABwTzsKFAC4sy
 w2F9nhdHzacaky93HqnLFPtCaEVj4le7fUxhRRyNKtHnX3rz40THJAaizGrrr1KG
 /h33+xsLvP3xfDqN/GkBfUtQ+1Dt6CKUjPMtjE2rtesTjRrsYR/0Q9TuzC/1DQ1q
 Kh7YDoQJY8pN1raVIQ/XYcNnqes7DeYAnD+QhdQRQGSn9+jXoEV3iMk1AsS95nYf
 1ZuV7hRToPhwAOGxOgPR/qI18vKBM2JlLrfmfbaz1tJHZFLek2DjZp3LO6XU7LCt
 LrKUQoNuyBekq8dLWQ0i9LZtFxJ5fLiV/aMEVM+4SYsqALlHvgWv1/QO4Fzvbqmk
 ayrUkFp7ODlualrhISwLnKWNG7yLCBhtTlc2RW6T9ge/6CMRk4vSg1sRrS8uVfft
 0FJ5PYQ8SuXtwI/9QYxAB1lVhdJqDZkdeivi1/A3jXFDUPAGYsGlTt/6f0qesbat
 XBw5UoXhzaJqm9xQ1gHQeoIwkgFV4v6fI4KUu3PIxc12U4j8Q4BtufS0ZH/MqbGC
 XcX5pzA6PGB4Vdk2Za9qtuZguF4Rdr/zllh08f0deqxl+U8zD1Sg9SBpg9Hgnexr
 Ym19nsC8GaC95o4DDwF+
 =Gp+L
 -----END PGP SIGNATURE-----
 

Reorganize how Solution handles pinned states and constraints. (#1373)

Reorganize how Solution handles pinned states and constraints.

In the process of turning ListElement into a Piece, I ran into a couple
of bugs in how pinned states and constraints between pieces are handled.

The tests didn't catch those bugs because there are basically two bugs
that cancel out. The IfPiece was incorrectly pinning an empty else block
in an if statement to split. But the solver was incorrectly ignoring
pinned states in some cases. This fixes both bugs.

With this change, when generating a Solution, we eagerly bind as many
Pieces to States as we can when the Solution is first created before
running CodeWriter. To do that, we find all of the pinned Pieces and
bind them to their pinned States, then propagate any constraints from
that to other child Pieces.

This fixes a couple of bugs, but also, I think, leads to a cleaner
module where at Solution creation time, we fill in as many piece states
as we can based on what we know statically about the Piece tree (its
pinned states and their constraints). Then during solution exploring and
line splitting, we don't have to worry about pinned states at all.

This will, I think, align with future optimizations where we do some
other piece pinning before running the solver.