You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix bug in subtree merging cost calculation. (#1377)
An important optimization during solving is hoisting out a separable
Piece subtree, formatting in its own isolated Solver, and then merging
the resulting Solution back into the parent Solution.
When we merge, we add in all of the data from the subtree to the main
one. It's important that doing so yields the exact same result that we
would get if we had solved that subtree directly inline in the parent
Solution.
Unfortunately, the previous code didn't do that. In some cases, pieces
that are bound by the subtree Solution would already be bound in the
parent one too. In that case, merging would double-count the cost of
those pieces.
This fixes that by only counting the cost of pieces that weren't already
bound in the parent.
I ran into this bug while running the large benchmark and it was
surprisingly hard to hoist out a small separable test case. The issue
wasn't really specific to any particular Piece or syntax. It's really a
regression test.
The regression tests aren't migrated for the new formatter yet, so I
made a new directory "regression_tall" and put it there. I'm not sure if
that's ultimately the naming convention we'll want.
Also, while I was investigating this, I noticed that ListPiece could
theoretically try to format a child Piece separately when doing so
wasn't valid because there might be code from a sibling or parent piece
on its line. (In practice, that can't happen because the only
SequencePiece that doesn't have surrounding brackets is the one
top-level sequence for the compilation unit. So there definitely won't
be anything before or after that. But if we ever use SequencePiece in
other places without brackets, this avoids that becoming a bug.)
0 commit comments